boost::optional with BOOST_FUSION_ADAPT_ADT broken?
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. C++ wizard,
K-Ballo, took a quick look at this in #boost and seemed to suggest
it's the way op= is SFINAEd up for optional.
Does anyone have a work around for this?
#include
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. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
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/
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
On 2/28/14, 6:09 AM, Agustín K-ballo Bergé wrote:
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?
Hmmm. That might be too all encompassing. There might be a way to limit the effect only for ADT adaptor proxies. Thinking out loud... Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/
participants (3)
-
Agustín K-ballo Bergé
-
Andrew
-
Joel de Guzman