Re: C++17 skeleton with move semantics and std::variant

[Hans Åberg]

> On 9 Apr 2018, at 16:55, Frank Heckenbach <address@hidden> wrote:
> 
> Hans Åberg wrote:
> 
>>>> Akim Demaille gave two motivations on not using this: avoiding the
>>>> external dependency, and the overhead of storing the type. I think
>>>> that the C++17 variants may have the latter, but it is not so
>>>> important on modern computers.
>>> 
>>> Yes, they do, and it's needed. That's exactly what fixes the
>>> problems with $<type> -- the type must be stored somewhere.
>>> 
>>> Not storing the type seems a nifty idea with Bison which knows about
>>> the type most of the time, but it breaks down just there.
>> 
>> Perhaps there is a bug in %union in the same place then, as it does not 
>> store the type.
> 
> I'm not so familiar with the C skeleton, but I think the difference
> is that %union is completely unchecked. Store foo, retrieve foo, all
> is fine; store foo, retrieve bar, get garbage (UB).
> 
> Whereas the C++ skeleton adds some checking (only statically) which
> results in $<type> not working at all. If it didn't do that (that's
> where I wrote "if not for the previous bug"), the behaviour would be
> similar to the C version, just a bit worse when types with
> non-trivial constructors/destructors come into play.
> 
> So for C++ we could either go back and disable the static type
> checking completely, or do full dynamic checking (which std::variant
> does by itself). I choose the latter. As you said, the performance
> impact should be small, and the safety benefit substantial. (If
> someone doesn't want it, they might be able to use an alternative
> variant implementation without checks, or not use variant at all
> ...)

That might be the difference: C++, unlike C, needs the types to select the 
right constructors. To get those and not only PODs was one motivation for 
introducing the variants.