Re: [Boost-users] boost::optional with BOOST_FUSION_ADAPT_ADT broken?

Subject: Re: [Boost-users] boost::optional with BOOST_FUSION_ADAPT_ADT broken?
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-02-27 17:09:46

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