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

Subject: Re: [boost] [contract] auto_..._error regression tests fail on C++1z
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-10-04 18:44:13

On 10/4/2017 12:48 PM, 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_[hidden]>
>>>
>>> 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.

I think you mistyped and should have written:

"but I should still get a compile-time error if I try to use a copy
operation on a type that does not allow copy, even when these copies are
guaranteed to be optimized away in C++11z."

I agree with that sentiment also, so I am equally surprised that a 
compile-time error does not occur. I would be very interested in the 
part of the C++17 standard which explains why I do not get a 
compile-time error in the example case where f() is a private function.

> 
> Thanks.
> --Lorenzo