Re: [boost] [optional] Regression in develop

Subject: Re: [boost] [optional] Regression in develop
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-10-30 08:59:29

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/9779157a787620d163308afa45cb94ef42391b32
>
> 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.

Is the current issue restricted to std::pairs?

> 2. Disable my feature on the compilers with buggy support. But I would need
> a help from someone who knows all the compilers and their bugs in
> implementation of trivial type traits so that I can put the wight `#ifdef`s.

Seems to just be VC12 based on the CI test results?

> 3. Just revert my changes to Optional, which is also an option, but would
> also be a loss.

Indeed.

Maybe not helping much, yours, John.

---
This email has been checked for viruses by AVG.
http://www.avg.com