On 27/02/2014 02:01 p.m., Joel de Guzman wrote:
On 2/27/14, 10:03 PM, Agustín K-ballo Bergé wrote:
On 27/02/2014 10:21 a.m., Andrew wrote:
There's an issue using get expressions returning optionals with BOOST_FUSION_ADAPT_ADT, demonstrated in the simplest case below. Optional<T> is trying initialize its internal T object using the attribute proxy object returned by fusion, but this can only degrade to optional<T> and not T, so the assignment fails. K-Ballo, took a quick look at this in #boost and seemed to suggest it's the way op= is SFINAEd up for optional.
Optional's assignment operator is not SFINAEd at all. If it were, it might allow fusion to get away with its implicitly convertible attribute proxies.
The fundamental problem is that fusion lies about adapted ADTs, since those are sequences of proxies instead of sequences of whatever you asked for. Fusion could do better to support its own proxies by adding explicit conversions wherever those conversions are expected to happen implicitly now. But that's not a general solution, and I don't think there is one besides documenting that adapted ADTs are not quite sequences.
They are sequences. Not sequences of Ts though, but sequences of proxies to Ts.
Nod. I was extrapolating the requirements for a standard sequence (homogeneous), and considering how `vector<bool>` returns proxies and thus it does not model the concept of a sequence.
Perhaps we can add customization points that the user can hook into to work around cases like this?
Something like an `implicit_cast` extension point, and then wrap all input iterator dereferences within algorithms? Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com