On Thursday, 9 January 2020 at 13:26:36 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis wrote:
>> On Wednesday, January 8, 2020 11:26:41 PM MST Walter Bright via Digitalmars- d wrote:
>>> I'm aware that C++ is moving away from exceptions. I've been unhappy with exceptions for some time now (DMD doesn't use them for performance reasons), and C++ has evidently come to the same conclusion.
>>>
>>> I expect that exceptions will soon become a legacy feature.
>>
>> I would really hope not. IMHO, they are usually by far the best way to handle error conditions in a program. Anything else results in you having to deal with the various possible error conditions when the function returns, which is _far_ more unwieldy and much more error-prone. It also doesn't work well with function call chaining.
>
> I doubt Stroustrup will let that happen. Highly unlikely scenario.
>
> Not sure why anyone would think that exceptions are gone just because some want to enable compilers configured to compile without exceptions to use more library containers (like std::vector)?
>
>  C++17 certainly introduced new exceptions (std::filesystem::filesystem_error), and I believe more C++ setups enable exceptions today than a decade ago. For good reasons.
>
> No need to avoid exceptions in the whole program just because you don't want them in som specific locations (like render code).
>
> Whole program analysis and inter-procedural analysis should be able to take care of it.

Unfortunately Stroustrup only has its own vote and lobbying in what concerns C++'s future, hence his set of advocacy papers regarding C++'s roadmap.

As posted in another comment, C++/WinRT and Android NDK are two such C++ setups.

On Thursday, 9 January 2020 at 13:45:44 UTC, Paulo Pinto wrote:
> As posted in another comment, C++/WinRT and Android NDK are two such C++ setups.

I don't use NDK, but the documentation states clearly that it only supports new and delete for historic reasons:

«C++ exceptions are supported by libc++, but they are disabled by default in ndk-build. This is because historically C++ exceptions were not available in the NDK. CMake and standalone toolchains have C++ exceptions enabled by default.»

https://developer.android.com/ndk/guides/cpp-support

On 1/9/20 7:51 AM, Adam D. Ruppe wrote:
> On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
>> I expect that exceptions will soon become a legacy feature.
> 
> I've seen no evidence of that whatsoever. Exceptions, like GC, are a proven winner in the real world with the vast majority of actually existing industry code using them successfully.
> 
> Reminder that exceptions were invented because error codes *cannot* say the same thing.
> 
> There are some new techniques being tried out in some places to varying levels of success. Those features are useful for other purposes too, so I wouldn't mind D picking some of them up, like I said in a previous message.
> 
> But even with those available, I expect that error handling mode will remain relatively niche because of the enormous success exceptions have and have had proven in industry.
> 

I could see "nothrow by default" added making it an easier transition to Swift-like error handling (errors passed back on the stack, made to look like exceptions to user code).

I would like to see dip1008 get some more TLC before we think about abandoning exceptions altogether. And switching Errors to non throwables, terminate in place with stack trace, would be very useful.

-Steve

On Thu, Jan 09, 2020 at 10:07:53AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 1/9/20 7:51 AM, Adam D. Ruppe wrote:
> > On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
> > > I expect that exceptions will soon become a legacy feature.
> > 
> > I've seen no evidence of that whatsoever. Exceptions, like GC, are a proven winner in the real world with the vast majority of actually existing industry code using them successfully.

+1.  This anti-exception sentiment I have a hard time understanding.


[...]
> I could see "nothrow by default" added making it an easier transition to Swift-like error handling (errors passed back on the stack, made to look like exceptions to user code).
[...]

Now *this* I can stand by.  Which makes me wonder if what's bothering Walter about exceptions is not so much the concept of exceptions itself, but their current implementation via stack unwinding, which requires expensive setup of stack frames and what-not.

But it's possible to implement it differently, while still presenting an exception-like interface to user code. You could pass errors back on the stack, or even via a register dedicated for indicating error conditions, and have the compiler automatically generate code for branching to an error-handling part of the function (or have user code explicitly test for it, if they so wish). This can be transparent to user code.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

On Thursday, 9 January 2020 at 14:16:38 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 9 January 2020 at 13:45:44 UTC, Paulo Pinto wrote:
>> As posted in another comment, C++/WinRT and Android NDK are two such C++ setups.
>
> I don't use NDK, but the documentation states clearly that it only supports new and delete for historic reasons:
>
> «C++ exceptions are supported by libc++, but they are disabled by default in ndk-build. This is because historically C++ exceptions were not available in the NDK. CMake and standalone toolchains have C++ exceptions enabled by default.»
>
> https://developer.android.com/ndk/guides/cpp-support

Ah, the Android documentation, where Medium posts by Google employees and twitter posts, and back in the day G+ posts, are more up to date than the actual documentation.

https://android.googlesource.com/platform/ndk/+/ndk-r14-release/CHANGELOG.md

"RTTI and exceptions are now on by default. This was done for improved compatibility with existing CMake projects. See https://github.com/android-ndk/ndk/issues/212."

On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
> I expect that exceptions will soon become a legacy feature.

Honestly, to me this sounds like "I don't like/use exceptions therefore get rid of them (not as a feature, but just stop using it anywhere or make them too annoying to bother with)", which is understandable since you mostly seem to work on projects that require high-performance (like DMD), but not every project is unable to afford the overhead of exceptions.

In terms of making `nothrow` the default, I dread to think of how annoying it'd be for a commonly used function in a codebase to not be `nothrow`, then having to throw in the `throw` keyword into the ever-growing attribute soup for any function that calls it. While at the moment if a function is `nothrow`, then it's optional for a caller to be `nothrow` so it doesn't stick in my face as much.

I guess the same argument could be applied to @safe by default, but having to deal with an `@system` function is likely much rarer and confined than having to deal with a more widely used `throw` function, making it more manageable, while `@safe` also provide heavy benefits outside of just "performance".

I fear this will also discourage the use of exceptions, and push people to overuse error codes which don't have any standard pattern; aren't able to provide additional info beyond the actual error itself (e.g. can't provide certain info or values that caused the error); require the caller to produce any error messages (which might mean functions specifically designed for other functions' error codes); and more annoyingly either a type that returns both value and error (which isn't too bad, but a bit annoying), or requires the caller to pass an out/ref parameter(s) in case of an error (again, very annoying to deal with).

I don't know. It just feels like this proposal will add more friction with using D in the general case, as a compromise for giving extra performance in the niche case.

I'm a bit of a dimwit, so apologies if I've misunderstood how this'd end up working, but my current view is that it'd make my own experience with D more painful for unequal amount of benefit.

On Thursday, 9 January 2020 at 16:19:19 UTC, Paulo Pinto wrote:
> Ah, the Android documentation, where Medium posts by Google employees and twitter posts, and back in the day G+ posts, are more up to date than the actual documentation.

But the change log does not contradict the documentation... It says that exceptions/STL are not shipped in the system runtime, but has to be embedded in the app bundle.

Anyway, it does not matter. The point was only that it was for historic reasons, and that supporting exceptions are part of the available platform.

On Thursday, 9 January 2020 at 10:32:25 UTC, Jonathan M Davis wrote:

> IMHO, having nothrow be the default would be terrible, and trying to treat exceptions as a legacy feature would be even worse.

+1

Huge mistake in terms of programmer convenience. I don't really care what Rust or other languages are doing. I'm using D right now for a reason.

Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:

> On Thu, Jan 09, 2020 at 10:07:53AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 1/9/20 7:51 AM, Adam D. Ruppe wrote:
>> > On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
>> > > I expect that exceptions will soon become a legacy feature.
>> > 
>> > I've seen no evidence of that whatsoever. Exceptions, like GC, are a proven winner in the real world with the vast majority of actually existing industry code using them successfully.
> 
> +1.  This anti-exception sentiment I have a hard time understanding.
> 
> 
> [...]
>> I could see "nothrow by default" added making it an easier transition to Swift-like error handling (errors passed back on the stack, made to look like exceptions to user code).
> [...]
> 
> Now *this* I can stand by.  Which makes me wonder if what's bothering Walter about exceptions is not so much the concept of exceptions itself, but their current implementation via stack unwinding, which requires expensive setup of stack frames and what-not.
> 
> But it's possible to implement it differently, while still presenting an exception-like interface to user code. You could pass errors back on the stack, or even via a register dedicated for indicating error conditions, and have the compiler automatically generate code for branching to an error-handling part of the function (or have user code explicitly test for it, if they so wish). This can be transparent to user code.
> 
> 
> T

I think everyone who wants to move away from exceptions really wants to move away from two things:

1) Stack unwinding and the overhead it involves (memory, implementation
   complexity, ...)
2) (Forced) dynamic allocation of error state. How often do you actually
   use more than 1 word of error state?

That's basically what Sutter proposes for C++, what I summarized in https://forum.dlang.org/post/qusdvn$635$1@digitalmars.com and what you quickly summarized in your idea.

AFAICS nobody (few people?) wants to get rid of the high-level try-catch exception semantics.

However, some might not want to catch by runtime type but implement the catch matching using some kind of error codes. The only thing you loose here is having complex exception type trees and catching base classes.

Also as I explained in the linked post, try-catch is fine if you handle multiple error sources a once. If you instead have to handle errors for each function call individually, a more fine grain solution than

try
{
    auto foo = someFunction();
    try
    {
        foo = someFunction2(foo);
    }
    catch(Exception3 e)
    ...
    catch(Exception4 e)
}
catch(Exception e)
 ...
catch(Exception2 e)

would be useful in addition.

-- 
Johannes

On Thu, Jan 09, 2020 at 07:05:24PM -0000, Johannes Pfau via Digitalmars-d wrote:
> Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:
[...]
> I think everyone who wants to move away from exceptions really wants to move away from two things:
> 
> 1) Stack unwinding and the overhead it involves (memory,
>    implementation complexity, ...)
> 2) (Forced) dynamic allocation of error state. How often do you
>    actually use more than 1 word of error state?

What can you practically throw, though, if you only have 1 word of error state? I suppose you could store a pointer to some exception object in there, but then that brings us back to issue (2). Unless you have some kind of thread-local global for storing exception objects?


> That's basically what Sutter proposes for C++, what I summarized in https://forum.dlang.org/post/qusdvn$635$1@digitalmars.com and what you quickly summarized in your idea.
> 
> AFAICS nobody (few people?) wants to get rid of the high-level
> try-catch exception semantics.
[...]

That's also my suspicion.  It's not really the exceptions themselves that people object to, but the associated implementation issues.


T

-- 
Just because you can, doesn't mean you should.