Zitat von Christopher Schmidt <mr.chr.schmidt@online.de>:
I think simply providing a sequence of proxies is less error-prone than trying to hide it when possible.
I don't agree. The proxy is indeed clumsy, but due to being implicitly convertible to the underlying type it does its job quite well. In most use-cases an adapted 'class' does feel just like any other regular fusion container.
our positions aren't really that far apart from each other: yours: for_each(s,f); //sometimes works ref_for_each(s,f); //always works mine: for_each(s,f); //never works for_each(s,deproxify(f)); //always works
In my opinion, fully exposing the proxy type is not conducive as the type of interest is always the type encapsulated by the wrapper. The proxy is just a means to an end. If the special traits of proxies are ditched, that is if the implicit conversion ability is removed and the proxy is exposed as the actual value type, all generic user code will need to handle proxy types explicitly. Generic user tmp code would probably need hacky mpl-code that distinguishes fusion proxies from non-proxy value types. Generic run-time functors would need to be specialized for proxies. That is prone to errors! With the current design, only very few run-time functors have to be specialized for proxies at all.
Stefan, considering your special use-case: if the proxy's underlying
is it that special? I wanted to show the const/non-const issue with it, so I guess it is, but doesn't even a simple transformation fail with proxies? template<typename T> T identity(T const &t){ return t; } fusion::transform(s,identity_obj); (with identity_obj being a generic function object that implements identity) basically any functor that doesn't force the proxy to implicitly convert the proxy to its value might not work as envisioned by the implementor of the functor (without having proxies in mind)