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. Perhaps we can add customization points that the user can hook into to work around cases like this? Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/