Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-08-17 02:38:49

Zitat von Christopher Schmidt <mr.chr.schmidt_at_[hidden]>:

>>> 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)