September 10, 2021
On Friday, 10 September 2021 at 15:26:18 UTC, Kagamin wrote:
> Nullable doesn't replace exceptions, it specifies a value which is legitimately absent, not due to an error, it's `Result` that replaces exceptions. Also languages built with this pattern in mind have syntax sugar that helps propagate those errors upwards.

Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D. Since then I haven't seen any proposal for any new error handling for D.
September 11, 2021
On Friday, 10 September 2021 at 23:20:17 UTC, IGotD- wrote:
ve syntax sugar that helps propagate
>
> Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D. Since then I haven't seen any proposal for any new error handling for D.

There has been some brainstorming about it, but don't expect to see a proposal anytime soon.
September 11, 2021

On Friday, 10 September 2021 at 23:20:17 UTC, IGotD- wrote:

>

Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D. Since then I haven't seen any proposal for any new error handling for D.

Well the @nodiscard proposal, that is very likely to get accepted, is sort-of one. It's basically about returning traditional error values, but forcing the user to be explicit if she really wants to summarily discard them.

September 11, 2021
On Sat, Sep 11, 2021 at 08:13:07PM +0000, Dukc via Digitalmars-d wrote:
> On Friday, 10 September 2021 at 23:20:17 UTC, IGotD- wrote:
> > 
> > Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D.  Since then I haven't seen any proposal for any new error handling for D.
> 
> Well the `@nodiscard` proposal, that is very likely to get accepted, is sort-of one. It's basically about returning traditional error values, but forcing the user to be explicit if she really wants to summarily discard them.

Whatever replaces exceptions better be darned good, otherwise I will be very unhappy.  Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.  I don't really buy the performance argument: if your profiler pinpoints try/catch blocks as the bottleneck, it's not hard to refactor it to use error codes instead. Anything else is premature optimization.  We should not uglify code just for some idealism that exceptions are somehow "bad".


T

-- 
EMACS = Extremely Massive And Cumbersome System
September 12, 2021

On Sunday, 12 September 2021 at 01:50:37 UTC, H. S. Teoh wrote:

>

On Sat, Sep 11, 2021 at 08:13:07PM +0000, Dukc via Digitalmars-d wrote:

>

On Friday, 10 September 2021 at 23:20:17 UTC, IGotD- wrote:

>

Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D. Since then I haven't seen any proposal for any new error handling for D.

Well the @nodiscard proposal, that is very likely to get accepted, is sort-of one. It's basically about returning traditional error values, but forcing the user to be explicit if she really wants to summarily discard them.

Whatever replaces exceptions better be darned good, otherwise I will be very unhappy. Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.

Rust's monadic error handling is frequently ugly, but there's a cultural backing to it; the feature itself doesn't demand all that ugliness. As soon as you change the culture you can have solutions like

// halt program on empty nums
int find_gcd(const int[] nums) nothrow {
    import std.numeric : gcd;
    import mod.algorithm : minElement, maxElement;

    return gcd(nums.minElement.unwrap, nums.maxElement.unwrap);
}

vs.

// return None on empty nums with ? syntax
auto find_gcd(const int[] nums) nothrow {
    import std.numeric : gcd;
    import mod.algorithm : minElement, maxElement;

    return gcd(nums.minElement?, nums.maxElement?);
}

vs.

// throw catchable exception on empty nums
int find_gcd(const int[] nums) {
    import std.numeric : gcd;
    import mod.algorithm : minElement, maxElement;

    return gcd(nums.minElement, nums.maxElement);
}

with the compiler or some alias this magic inserting code that checks the Option!int returns and throwing on None.

i.e., if you want it you get the explicit error handling, and if you don't want it you get exceptions, and you can guard against unwanted 'helpful' automatic exceptions with nothrow.

September 12, 2021
On Sunday, 12 September 2021 at 01:50:37 UTC, H. S. Teoh wrote:
> On Sat, Sep 11, 2021 at 08:13:07PM +0000, Dukc via Digitalmars-d wrote:
>> On Friday, 10 September 2021 at 23:20:17 UTC, IGotD- wrote:
>> > 
>> > Walter mentioned that exceptions are on the way out because they are expensive and inhibits the optimizer which are fair points. I interpreted this that Walter wants to move away from exceptions in D.  Since then I haven't seen any proposal for any new error handling for D.
>> 
>> Well the `@nodiscard` proposal, that is very likely to get accepted, is sort-of one. It's basically about returning traditional error values, but forcing the user to be explicit if she really wants to summarily discard them.
>
> Whatever replaces exceptions better be darned good, otherwise I will be very unhappy.  Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.  I don't really buy the performance argument: if your profiler pinpoints try/catch blocks as the bottleneck, it's not hard to refactor it to use error codes instead. Anything else is premature optimization.  We should not uglify code just for some idealism that exceptions are somehow "bad".
>
>
> T

Yes, one thing that gets lost is the boilerplate required to create error types, to the point that there are crates to work around it.

https://users.rust-lang.org/t/how-to-reduce-boilerplate-when-wrapping-errors/39363/6

Beware what you wish for, the grass is not always greener on the other side.
September 12, 2021
On Sunday, 12 September 2021 at 01:50:37 UTC, H. S. Teoh wrote:
>
> Whatever replaces exceptions better be darned good, otherwise I will be very unhappy.  Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.  I don't really buy the performance argument: if your profiler pinpoints try/catch blocks as the bottleneck, it's not hard to refactor it to use error codes instead. Anything else is premature optimization.  We should not uglify code just for some idealism that exceptions are somehow "bad".
>
>
> T

What about the C++ approach, return values that look like exceptions.

You probably have already seen it.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf

We are allowed to "steal" from C++ if it is any good. Also it can be good for interoperability.
September 13, 2021
On 13/09/2021 3:53 AM, IGotD- wrote:
> On Sunday, 12 September 2021 at 01:50:37 UTC, H. S. Teoh wrote:
>>
>> Whatever replaces exceptions better be darned good, otherwise I will be very unhappy.  Explicit exception handling has its place, but in other cases it just uglifies code for no good reason.  I don't really buy the performance argument: if your profiler pinpoints try/catch blocks as the bottleneck, it's not hard to refactor it to use error codes instead. Anything else is premature optimization.  We should not uglify code just for some idealism that exceptions are somehow "bad".
>>
>>
>> T
> 
> What about the C++ approach, return values that look like exceptions.
> 
> You probably have already seen it.
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
> 
> We are allowed to "steal" from C++ if it is any good. Also it can be good for interoperability.

I recently posted a similar design here: https://forum.dlang.org/post/she82k$g31$1@digitalmars.com

A big difference between the one you linked and mine is the throws keyword takes the types that can be thrown. So an empty set of throwables, is the same as none being thrown.

The other difference is to recognize that it is not a return value, rather it is an out parameter instead that is hidden like this is. This allows for the purpose of playing nicely with existing code.
September 12, 2021
On Sunday, 12 September 2021 at 15:53:16 UTC, IGotD- wrote:
>
> What about the C++ approach, return values that look like exceptions.
>
> You probably have already seen it.
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
>
> We are allowed to "steal" from C++ if it is any good. Also it can be good for interoperability.

Feels like java throws statement, except the need to handle exception in the function that calls throwing function.


September 13, 2021
On Sunday, 12 September 2021 at 22:50:49 UTC, Alexandru Ermicioi wrote:
> On Sunday, 12 September 2021 at 15:53:16 UTC, IGotD- wrote:
>>
>> What about the C++ approach, return values that look like exceptions.
>>
>> You probably have already seen it.
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
>>
>> We are allowed to "steal" from C++ if it is any good. Also it can be good for interoperability.
>
> Feels like java throws statement, except the need to handle exception in the function that calls throwing function.

Java throws statement was based on CLU, Modula-3 and C++, actually.

Herb's idea is based on how Swift does exceptions, and ironically brings exception specifications back into C++, after their removal on C++17, just written in a different form.