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
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.
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