Re: [boost] [optional] Regression in develop

Subject: Re: [boost] [optional] Regression in develop
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-10-30 10:23:06

2017-10-30 9:59 GMT+01:00 John Maddock via Boost <boost_at_[hidden]>:

>
>
> On 30/10/2017 07:47, Andrzej Krzemienski via Boost wrote:
>
>> Hi Everyone,
>> Over the weekend I added changes to Boost.Optional in develop which caused
>> regression in Boost.Beast and maybe more libraries. I would like to ask
>> for
>> your input as to how to best approach this.
>>
>> The change was: for trivial `T` use a different specialization of
>> `optional<T>` which is trivially-copyable. For this, I need the ability to
>> declare defaulted functions, and to detect that a given type is trivial.
>>
>> Boost.TypeTraits do not have `is_trivial` trait, so I compose it form
>> `has_trivial_move` and the like. But it seems there are compilers for
>> which
>> Boost.config and Boost.TypeTraits report support for deleted
>> functions/triviality detection, but where this support is buggy. The
>> following is a test case in type_traits by Vinnie Falco:
>> https://github.com/boostorg/type_traits/pull/52/commits/9779
>> 157a787620d163308afa45cb94ef42391b32
>>
>> In addition, the deadline for changes in release 1.66 is getting nigh. I
>> can see a couple of ways to fix this:
>>
>> 1. Fix Boost.Config and/or Boost.TypeTraits so that they only report
>> support for the features in question when it is supported without bugs.
>> But
>> I do not know if there is enough time for this given the deadline.
>>
>
> I'm mildly against that in Boost.Config: the issue seems to be VC12, which
> certainly does support deleted constructors, the issue is that the errors
> generated from their attempted use occurs "late" in the instantiation cycle
> so that it doesn't play well with meta-programming.  Besides, even if we
> disable deleted functions in our code, that doesn't stop users
> instantiating optional<user_defined_type_with_deleted_constructors> and
> hitting the same issue.
>
> In TypeTraits, there is an obvious and trivial workaround for the
> std::pair<> case, but other templates may still hit the same issue unless
> someone can devise a version of is_default_constructible that works with
> VC12 (I don't see an obvious alternative at present).  I could also make
> is_default_constructible non-functional for VC12, but that seems to
> needlessly harm folks that aren't using deleted constructors.
>

Maybe provide a yet another type trait, like
`is_sfinae_friendly_default_constructible`?
Or, maybe provide a macro that would tell if on this platform I get a 100%
correct behavior on `is_default_constructible` and
`has_trivial_default_constructor`?`

Regards,
&rzej;