On Monday, 23 November 2020 at 10:58:29 UTC, Jacob Carlborg wrote:
> On Sunday, 22 November 2020 at 17:37:18 UTC, Roman Kashitsyn wrote:
>> In the video from DConf 2020 about @live functions (https://youtu.be/XQHAIglE9CU) Walter mentioned that all @live functions are nothrow.  He also thinks that exceptions are obsolete.
>
> I haven't watched the video yet, but in general I think we need some form of error handling that more or less have the same semantics as the existing one. There are other ways to implement what looks like exception. Just look at the error handling in Swift, Zig and the proposal for C++ [1]. I think without any form of language support and syntax sugar, error handling is going to be a pain.

To get better C++ interop the best solution is to do whatever C++ does and focus on the ability to catch C++ exceptions in D code and vice versa.

On Monday, 23 November 2020 at 02:14:33 UTC, Vladimir Panteleev wrote:
> Another approach that I'm not sure we've explored fully is to outright deprecate silently discarding all function return values. Functions which return a value that is only sometimes useful seem like a relatively rare oddity.

The main advantage of @nodiscard compared to this approach is that it can interact with the type system. For example, if I declare a struct like the following:

@nodiscard Result(T, E)
{
    SumType!(T, E) payload;
    // ...
}

...then every expression that evaluates to a Result (not just function calls!) automatically becomes non-discardable.

On Monday, 23 November 2020 at 02:27:22 UTC, Adam D. Ruppe wrote:
> On Monday, 23 November 2020 at 02:14:33 UTC, Vladimir Panteleev wrote:
>> Some valid patterns were affected though, such as returning `this` (as in the builder pattern). Perhaps it would make more sense to instead allow annotating functions as that it's safe to discard their return value (@discardable or such)?

> I currently lean toward @nodiscard as being easier to use but I do expect @discardable would work pretty well too, just with a more involved transition period.

At least pure functions should never be @discardable.
So discarding the return value of a pure function should always be an error.

At my work we use the annotation "noSideeffects" (in C), which is pretty much the same as pure I think, except the poor syntax (need to repeat the function name in a separate macro line).
Depending on this an error is set if the return value is discarded. Works like a charm.

On Monday, 23 November 2020 at 12:07:55 UTC, Dominikus Dittes Scherkl wrote:
>
> At least pure functions should never be @discardable.
> So discarding the return value of a pure function should always be an error.

Indeed, the D compiler already issues a warning if you discard the result of a pure nothrow function.

On Monday, November 23, 2020 3:58:29 AM MST Jacob Carlborg via Digitalmars-d wrote:
> On Sunday, 22 November 2020 at 17:37:18 UTC, Roman Kashitsyn
>
> wrote:
> > In the video from DConf 2020 about @live functions (https://youtu.be/XQHAIglE9CU) Walter mentioned that all @live functions are nothrow.  He also thinks that exceptions are obsolete.
>
> I haven't watched the video yet, but in general I think we need some form of error handling that more or less have the same semantics as the existing one. There are other ways to implement what looks like exception. Just look at the error handling in Swift, Zig and the proposal for C++ [1]. I think without any form of language support and syntax sugar, error handling is going to be a pain.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Yeah, there are plenty of times where using a solution other than exceptions makes more sense, but in general, exceptions are by far the cleanest and simplest way to deal with error conditions, and I would _really_ hate to see D move away from them as the default error handling mechanism. Personally, I really don't care much about how they're implemented underneath the hood, but the ability to throw an error condition up to code that handles it higher up, allowing all of the code in between to largely ignore the error condition is huge, and a lot of code can get pretty disgusting without that.

- Jonathan M Davis

On Tue, Nov 24, 2020 at 01:30:33PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Monday, November 23, 2020 3:58:29 AM MST Jacob Carlborg via Digitalmars-d wrote:
[...]
> > [...] I think without any form of language support and syntax sugar, error handling is going to be a pain.
[...]
> [...] in general, exceptions are by far the cleanest and simplest way to deal with error conditions, and I would _really_ hate to see D move away from them as the default error handling mechanism.

I've said before, and I'll say again: I suspect that most (all?) of the current objections against exceptions comes from the current *implementation* of it, i.e., libunwind, et al..  There are other ways to implement the concept of exceptions that can potentially avoid these issues.

For example, instead of inserting stack frames and stack unwinding code, just use a dedicated register or CPU flag that indicates an error in the caller.  The callee detects this and branches to the cleanup code at the end of the function.  Then try/throw/catch become essentially just syntactic sugar for C-style error return codes.  The syntactic function return value essentially behaves like an implicit out parameter that conveys the return value.  Most complex C code is written more-or-less along these lines anyway, so this isn't really anything new.

Interfacing with C/C++ code will be trickier, of course, but not insurmountable. E.g., make it so that extern(C) will conform to the usual ABI, but extern(D) will use the new function call convention. Then native D code can benefit from this, while still be able to interface with C code via an extern(C) layer.


> Personally, I really don't care much about how they're implemented underneath the hood, but the ability to throw an error condition up to code that handles it higher up, allowing all of the code in between to largely ignore the error condition is huge, and a lot of code can get pretty disgusting without that.
[...]

+1.


T

-- 
Береги платье снову, а здоровье смолоду.

On Tuesday, 24 November 2020 at 22:14:03 UTC, H. S. Teoh wrote:
>
> I've said before, and I'll say again: I suspect that most (all?) of the current objections against exceptions comes from the current *implementation* of it, i.e., libunwind, et al..  There are other ways to implement the concept of exceptions that can potentially avoid these issues.
>

There is one thing that I think must go in D and that is chaining exception, catching several exceptions. As it is today this requires memory allocation itself and I'm not sure that we can support exception chains without memory allocation.

My experience is that looping through exceptions is extremely unusual and normally it is a first served approach that is used. Double, triple or more faults is often too difficult to deal with.

On Tuesday, 24 November 2020 at 22:14:03 UTC, H. S. Teoh wrote:
> I've said before, and I'll say again: I suspect that most (all?) of the current objections against exceptions comes from the current *implementation* of it, i.e., libunwind, et al..

D used to use a different implementation that I frankly thought was superior.

But it moved to this one for compatibility with other languages....

Another issue with D's exceptions is the allocation one. dip1008 seems ok though. Or I tried immutable ones but immutable w/ catch is broken af :(

On Tue, Nov 24, 2020 at 10:25:23PM +0000, IGotD- via Digitalmars-d wrote: [...]
> There is one thing that I think must go in D and that is chaining exception, catching several exceptions. As it is today this requires memory allocation itself and I'm not sure that we can support exception chains without memory allocation.
> 
> My experience is that looping through exceptions is extremely unusual and normally it is a first served approach that is used. Double, triple or more faults is often too difficult to deal with.

Yeah, chained exceptions are one of those things that look good on paper, but in practice rarely used, yet if you look at druntime, there's a bunch of very delicate and tricky (and ugly) code that's there just to handle chained exceptions.  In retrospect, we should've just made it so that throwing while another exception is in transit should just abort the program, like C++ does (IIRC).

Now we probably can't replace that without breaking stuff. (Though honestly, I doubt if anything would actually break besides the test suite!)


T

-- 
If blunt statements had a point, they wouldn't be blunt...

On Tue, Nov 24, 2020 at 10:41:16PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 24 November 2020 at 22:14:03 UTC, H. S. Teoh wrote:
> > I've said before, and I'll say again: I suspect that most (all?) of the current objections against exceptions comes from the current *implementation* of it, i.e., libunwind, et al..
> 
> D used to use a different implementation that I frankly thought was superior.
>
> But it moved to this one for compatibility with other languages....
[...]

Yeah.  And this is why aping other languages is not always a good idea. There must be adequate justification in-language for it; "language X does Y and therefore we must also do Y" is fallacious and leads nowhere good.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill