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

[Hans Åberg]

> On 14 Apr 2018, at 10:19, Frank Heckenbach <address@hidden> wrote:
> 
> Hans Åberg wrote:
> 
>>>> Before it gets integrated into the Bison distribution, you might
>>>> want to put it in the package source directory.
>>> 
>>> I won't for my code (but you, or anyone else, may want to). FWIW, I
>>> need patches to some Debian packages, some of them for years as many
>>> maintainers don't seem very interested in bug fixes (that don't
>>> affect them personally), unfortunately. So I keep a directory of all
>>> such patches, so I can easily reapply them after upgrades, and my
>>> Bison patch will just join them there, until it's integrated, or
>>> otherwise forever (probably not the only one): ...
>> 
>> I meant in the source directory of your program.
> 
> I understood that. I won't put it in my source directory, just like
> I won't put patches to JACK, FTGL and other long-time-no-maintenance
> packages there. I put those patches separately, install them once
> when I set up a new system, and keep my source code clean.

That wouldn't work in a distribution, as the user may not want or be able to 
change installation.

>>>> I was able to do it, with the following changes:
>>>> 
>>>> In the .yy file, I had to put in "./", to:
>>>> %skeleton "./lalr1-c++17.cc"
>>>> There seems to be a bug in Bison 3.0.4, looking only in the installation 
>>>> directory if it is not there.
>>> 
>>> Bug or feature, I don't know. Maybe it's supposed to work this way.
>> 
>> Check %skeleton in Bison Declaration Summary, 3.7.12.
> 
> So the behaviour seems correct, to find it in the current directory
> you do need "./":
> 
> : If file does not contain a /, file is the name of a skeleton file in
> : the Bison installation directory.

Yes. I was thinking about the program directory.

>>> I will now submit my changes to savannah. If the maintainers react
>>> to them, great, and we can discuss the details; otherwise, I think
>>> doing anything else now would just be a waste of time.
>> 
>> If you get it accepted, there may not be need for special file
>> names: It would suffice to set '#if (__cplusplus >= 201103L)'
>> around the C++11 code.
> 
> Not sure. My code changes user-visible behaviour (e.g. building of
> tokens, see my reply to Piotr), and changes the available
> %directives, so it doesn't seem suitable to make all that dependent
> on the compiler settings. Also, the skeletons would get (even more)
> unreadable, containing near-duplicated versions of a lot of code.

But if someone uses their of variants type, would that require C++11?

> I think in this regard, it's better to consider C++03 and C++17 two
> different languages, like C vs. C++. In the long run, maybe the
> C++03 skeleton can be faded out, but that's not my decision to make.

It would be best to just have one. But the variants may not have been used much.