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.

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

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

1. add a error code system to the range api
2. damn the consequences have fail safe functions(1/0==int.max)
3. store errors and extra control flow in my innate pattern
4. nullable everywhere, range functions can react to nullable elements
5. preallocate some space for exceptions, cap the size of exception objects(assuming this is about betterc)

On Thursday, 16 January 2025 at 19:13:38 UTC, monkyyy wrote:

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

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

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

Sum types?

On Thursday, 16 January 2025 at 19:38:45 UTC, Derek Fawcus wrote:

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

That's not the problem. remember the example

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

the problem is about keeping the same expressivity but eventually using another error handling system.For example imagine an error happens during the mapping, then what has to do the reducer ?

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

aborts are bad; hottake; nullables are far far better pattern

But 3 and 5 could be the same "bad goto" as exceptions with compiler help or some truly awful raw asm

3 could also abort on error with lib design, but that would be very ugly

nullable!int inverse(int i){
  if(i==0){return null;}
  return 100/i;
}
[2,0,5,4].map!inverse.sort==[null,20,25,50];

Could just exist, theres one of them eagerness vs lazyness tradeoffs here between eager exceptions and lazy nullables; Im very much in favor of the later and never use exceptions as intended(when phoboes throws, make an hack to make it go away)

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

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

So, why don't keep using exceptions?
If you're concerned about GC, try

-preview=dip1008

For me this works like a charm.

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

The Easiest Way To Handle Errors Is To Not Have Them

I don't have a general solution for your abstract formulation of the problem, but if you give examples of concrete mapper functions that you think have to throw an exception, I can give you my take on how to avoid it.

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

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

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 😛

On Thursday, 16 January 2025 at 23:04:20 UTC, Dom DiSc wrote:

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

I should have said it earlier but the context is another programming language than D. At the moment it has no builtin error handling system.