Re: [Patch] [add changelog] reduce template instantiation depth in <variant>

[Tim Song <t dot canens dot cpp at gmail dot com>]

On Sat, Nov 12, 2016 at 3:48 PM, Barrett Adair
<barrettellisadair@gmail.com> wrote:
> On Sat, Nov 12, 2016 at 2:39 PM, Tim Shen <timshen@google.com> wrote:
>> On Sat, Nov 12, 2016 at 4:28 AM, Daniel Krügler
>> <daniel.kruegler@gmail.com> wrote:
>>> 2016-11-12 10:04 GMT+01:00 Barrett Adair <barrettellisadair@gmail.com>:
>>>>>Currently, std::variant exceeds the default ftemplate-depth parameter when instantiated with 297 types. This small patch increases this ceiling to 446 types (from the bottom of the template stack).
>>>>
>>>> Sorry, first patch - I just read the guidelines. I changed the format
>>>> and added a changelog entry. I hope I did it correctly this time.
>>>
>>> Let me add that this patch suggestion causes a change in semantics in
>>> theory, because fold expressions have no short-circuit evaluation,
>>
>> Is it a compiler QoI problem, or part of the language? I'd be
>> surprised if the language somehow prohibits the short circuits from
>> happening.
>>

In the fold expression case, you are required to diagnose if any of the
is_meow_constructible<T>::value &c. is ill-formed, so in the general case
you have to instantiate them all.

>>> contrary to __and_. Whether this difference is relevant here is
>>> of-course something the maintainer has to decide.
>>>
>
> Since there are no side-effects, and the metafunctions in play cannot
> SFINAE, I don't believe the semantics are actually affected by
> short-circuiting in this case.

The issue is that the fold expression requires actually instantiating all the
is_meow_constructible &c. specializations (which in turn may trigger extra
instantiations) while __and_ only instantiates those needed for the result.
The extra instantiations can be expensive in terms of compile time but this,
of course, depends on the types involved. Some benchmarks would be nice.