17 hours ago

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

17 hours ago

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.

17 hours ago

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.

17 hours ago

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;
	...
}
17 hours ago

Or an error subrange?

V op(Range)(Range r)
{
	if(!r.error.empty)return r.error;
	...
}
16 hours ago

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.

7 hours ago

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.

4 hours ago

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

1 2
Next ›   Last »