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

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 wrote:

...

2017-09-29 4:29 GMT+02:00 Lorenzo Caminiti via Boost

...

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