1. Calling C++ code from C is done by creating wrapper C++ functions that hide all the C++ features (only use C types), and then we expose these functions via C compatible header and with the extern "C" stuff. With this proposal this will continue to be this way.
2. Calling C code from C++ comes (mostly) out of the box. Now lets say this proposal gets accepted into C. To get out of the box support for C code, in C++ _Fails, _Either have to be copied into C++ specs too. Now let's say zero-overhead deterministic exceptions get into C++. Now we have two syntaxes for the same feature. I don't like that. And maybe a third syntax will be needed to create the mappings.
   

On Friday, August 10, 2018 at 12:55:12 PM UTC+2, Jake Arkinstall wrote:

The question is, as far as I'm concerned, Why wouldn't you?

We are both facing a problem with error handling. The C approach doesn't scale, and the C++ approach is inefficient. So it is a known problem in both languages, for different reasons.

If you have to work with some C library in a C++ setting (e.g. sockets), you notice that your code becomes rather messy.

On 08/10/2018 09:34 AM, Niall Douglas wrote:
> Just to keep everybody on WG21 up to date, WG14 likes this proposal a lot, and apart from the .left, .right and .positive being replaced with _EitherValue(), _EitherError() and _EitherHasValue(), the above is essentially the paper to be published.
>
> Obviously if you have any additional feedback, please send it.

On Friday, August 10, 2018 at 11:22:56 AM UTC+1, Dimitrij Mijoski wrote:

From C++ point of view this seems to me like an implementation detail for the zero-overhead deterministic exceptions, rather than actual language specification. I'd rather see an actual implementation, than a specification that we don't know if it works. Only when you try to implement something, you will notice all the details you are probably missing now.

1. The names left and right are not descriptive for their uses. I would prefer expected and unexpected or value and error or something like that.

 

   b) The proposed rewrite from a setting of errno + a return statement to a return _Failure() seems scary as the programmer may insert some other code between the errno setting and the return statement.

 

   c) The code that shows the call site for the abs() example is not equivalent to the original as the function may set errno to 0, which is taken as no error by the original code but is still not "positive" by the new means.

       Upon further inspection it may be that this feature is just not explained clearly enough. I think your intention is that within a _Fails(errno) marked function errno is a local variable. If it is non-zero when a return statement is hit the transformation occurs.

       This seems to work better than my initial understanding that it is the code pattern of setting errno followed by return that is transformed.

 

   d) It is unclear to me what happens if errno is already != 0 when abs() is called. To get backwards compatibility it seems logical that the local errno gets set from the threadlocal errno when abs is entered. If this is the case, please show how the expression:

       abs(a) + abs(b) is translated (with the problem being that if abs(a) lazily returns an error then abs(b)'s initing of its errno would use a stale value).

 

3. In your last C example it is unclear if the code is the user written code or the compiler rewrite, and in the latter case if the user had a errno = 0 statement at all.

How `std::uncaught_exceptions` will exactly work with value exception? You mentioned overhead of cold cache, but it will be implemented in this or this is thing you want avoid?

I understand you're aiming at absolute minimum to improve chances
of success, but I wonder whether there is any plan to later on add
an stdbool.h-like header that gives these new symbols prettier
non-_Uppercase (non-implementation-reserved) names, like: