Re: [boost] [contract] auto_..._error regression tests fail on C++1z

Subject: Re: [boost] [contract] auto_..._error regression tests fail on C++1z
From: paul (pfultz2_at_[hidden])
Date: 2017-10-04 23:55:52

On Wed, 2017-10-04 at 09:48 -0700, Lorenzo Caminiti via Boost wrote:
> On Tue, Oct 3, 2017 at 11:45 PM, Andrzej Krzemienski via Boost
> <boost_at_[hidden]> wrote:
> > 
> > 2017-09-29 4:29 GMT+02:00 Lorenzo Caminiti via Boost <boost_at_lists.boost..or
> > g>
> > > 
> > > 
> > > Is there any way to make that `auto xx = f()` in main fail at compile
> > > time in C++1z?
> > > 
> > But why do you want this program to fail to compile?
> The library requires to explicitly use `boost::contract::check c =
> boost::contract::function()`. Using `auto c =
> boost::contract::function()` or `boost::contract::function()` (without
> assigning it to anything) will generate a run-time error. This is well
> documented. On non C++1z compilers, the library will also give a
> compile-time error if `auto c = boost::contract::function()` is used
> by mistake (but this no longer fails compilation on C++1z so you are
> left with just the run-time error in that case on C++1z).
> 
> In summary, this is just to catch a misuse of the API at compile-time
> instead of run-time... this is well documented so it shouldn't be a
> real issue in practice.
> 
> P.S. I'm surprised that I can no longer write a type in C++1z that
> will fail compilation when used via its copy operations... I wonder if
> that is an unintended consequence of the zero-copy optimization
> guarantee that C++1z has. Sure no copies should be made at run-time,
> but I should still get a compile-time error if I try to use a copy
> operation on a type that does allow copy, even when these copies are
> guaranteed to be optimized away in C++11z.

Yes, this is the semantic difference with guaranteed copy elision. So now
`NonMoveable x = NonMoveable{5}` is semantically equivalent to `NonMoveable
x{5}`. This is done by tweaking the value categories, so `NonMoveable{5}` no
longer produces a temporary object, but rather `NonMoveable{5}`(ie a prvalue)
performs initialization at the location of `NonMoveable x`(ie a glvalue).
There are exceptions where a temporary object will always be created(from
P0135):

* when a prvalue is bound to a reference
* when member access is performed on a class prvalue
* when array subscripting is performed on an array prvalue
* when an array prvalue is decayed to a pointer
* when a derived-to-base conversion is performed on a class prvalue
* when a prvalue is used as a discarded value expression

I dont know if any of those exceptions can help in your case. I ran into the
same problem with the Fit library, and was unable to find a workaround. 

It would be nice if compiler could provided the ability to force a temporary
object to always be created from a function.

Paul