<div dir="ltr"><div>There is, we discussed it informally at dconf quite a lot.</div><div></div><div>It looks like this:</div><div>

<a href="https://www.youtube.com/watch?v=GC4cp4U2f2E">CppCon 2018:  Brand & Nash “What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”</a>

</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 17 Jan 2025 at 05:05, Basile B. via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have the feeling that things like<br>
<br>
```<br>
a.map!(mapperFun).reduce!(reducerFun).array;<br>
```<br>
<br>
is only possible thanks to an exception system. A similar <br>
expressivity looks impossible for example with the idom of result <br>
tuple `(error_code, actuallResult)`.<br>
<br>
that problem is currently something rather serious, in the sense <br>
that, let's say you want to make a standard library, you really <br>
need to have a well defined way of handling errors.<br>
<br>
I'll be interested to read your thoughts on that topic.<br>
</blockquote></div>