January 17

On Thursday, 16 January 2025 at 19:37:36 UTC, Basile B. wrote:

>

I dont see how that helps to abort when an error happens "in between the chain" let's say.

Turn all operations into monadic combinators, example for Nullable: https://dlang.org/phobos/std_typecons.html#apply

January 17

On Friday, 17 January 2025 at 00:21:35 UTC, Meta wrote:

>

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

I have the feeling that things like

a.map!(mapperFun).reduce!(reducerFun).array;

is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple (error_code, actuallResult).

It's very easily doable, arguably with even better ergonomics than with exceptions:
https://fsharpforfunandprofit.com/rop/

C/C++ programmers are just stuck in the 80s 😛

Nice, thanks for the link, so finally it seems that the problem would be solved since 2014.

January 17

On Friday, 17 January 2025 at 08:43:00 UTC, Kagamin wrote:

>

On Thursday, 16 January 2025 at 19:37:36 UTC, Basile B. wrote:

>

I dont see how that helps to abort when an error happens "in between the chain" let's say.

Turn all operations into monadic combinators, example for Nullable: https://dlang.org/phobos/std_typecons.html#apply

Yeah that's also what's described in the talked pointed by Meta.

January 17

Nullable having range interface, maybe you can just add error to the range contract?

V op(Range)(Range r)
{
	if(r.hasError)return r.error;
	...
}
January 17

Or an error subrange?

V op(Range)(Range r)
{
	if(!r.error.empty)return r.error;
	...
}
January 17

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

I have the feeling that things like

a.map!(mapperFun).reduce!(reducerFun).array;

is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple (error_code, actuallResult).

that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors.

I'll be interested to read your thoughts on that topic.

I suggest to you to have a look how pure functional programming languages are handling such kind of constructs.

As a soft start I suggest Elm.

January 17

On Friday, 17 January 2025 at 09:35:03 UTC, Paolo Invernizzi wrote:

>

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

I have the feeling that things like

a.map!(mapperFun).reduce!(reducerFun).array;

is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple (error_code, actuallResult).

that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors.

I'll be interested to read your thoughts on that topic.

I suggest to you to have a look how pure functional programming languages are handling such kind of constructs.

As a soft start I suggest Elm.

While they should be part of the convrsation; purity is holding back ranges and we dont have the compiler tool set of haskell.

January 17

On Friday, 17 January 2025 at 00:21:35 UTC, Meta wrote:

>

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

I have the feeling that things like

a.map!(mapperFun).reduce!(reducerFun).array;

is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple (error_code, actuallResult).

It's very easily doable, arguably with even better ergonomics than with exceptions:
https://fsharpforfunandprofit.com/rop/

C/C++ programmers are just stuck in the 80s 😛

Some may be, others go with the times, courtesy of C++23.

https://en.cppreference.com/w/cpp/utility/expected

https://en.cppreference.com/w/cpp/utility/optional

https://en.cppreference.com/w/cpp/ranges

February 03

On Thursday, 16 January 2025 at 19:02:05 UTC, Basile B. wrote:

>

I have the feeling that things like

a.map!(mapperFun).reduce!(reducerFun).array;

is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple (error_code, actuallResult).

that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors.

I'll be interested to read your thoughts on that topic.

Koka programming language has cool effect system. Its powerful as monads, but pretty simple.
In D there is already the beginning of this system: pure, @safe, @nogc, nothrow. But in koka they are polymorphic. Also, these koka effects allow you to implicitly configure modules with the necessary callbacks. These effects also allow you to implement async/await, exceptions, generators, and some programs with complex flow control at the program level without having to change the compiler. https://koka-lang.github.io/koka/doc/book.html#sec-effect-types . If you add them to D, then you can transfer many D features to the runtime library altogether.

5 days ago
There is, we discussed it informally at dconf quite a lot.
It looks like this:
CppCon 2018: Brand & Nash “What Could Possibly Go Wrong?: A Tale of
Expectations and Exceptions” <https://www.youtube.com/watch?v=GC4cp4U2f2E>

At dconf while discussing this strategy, I had personally never heard of this proposal but the scheme we were discussing in detail at dconf turms out to be almost exactly what is presented in this lecture... which is a good sign! It's not new, and other people agree it's an excellent idea.

On Fri, 17 Jan 2025 at 05:05, Basile B. via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> I have the feeling that things like
>
> ```
> a.map!(mapperFun).reduce!(reducerFun).array;
> ```
>
> is only possible thanks to an exception system. A similar expressivity looks impossible for example with the idom of result tuple `(error_code, actuallResult)`.
>
> that problem is currently something rather serious, in the sense that, let's say you want to make a standard library, you really need to have a well defined way of handling errors.
>
> I'll be interested to read your thoughts on that topic.
>