On Monday, 12 January 2015 at 19:30:10 UTC, Russel Winder via Digitalmars-d wrote:
>
> On Mon, 2015-01-12 at 10:43 -0800, H. S. Teoh via Digitalmars-d wrote:
>> 
> […]
>> And what exactly should operator[] return if a key wasn't found?
>> 
> […]
>
> Go has an interesting solution, key lookup in a map return a pair
> (result, ok), if lookup succeeded then result is the associated value,
> if ok is false then result is undefined. I quite like this.

That's basically the same as a pointer to the value. If the pointer is null, dereferencing it is undefined.

On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote:
> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.

Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ.

The second approach is to pack the result in some kind of object that require checking (but you often don't have anything meaningful to do on failure where you need to check) or propagate the wrapper, à la maybe monad, and get rid of the wrapper where you know what to do on error.

These approach tend to be faster while keeping safety, but requiring more work from the dev. They make sense if the error is common, but are not pulling their weight for very rare failure scenarios like disc running out of space.

On Monday, 12 January 2015 at 20:07:17 UTC, deadalnix wrote:
> On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote:
>> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
>
> Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ.

It is difficult to introduce exceptions without causing problems
for linear typing.

http://www.serc.iisc.ernet.in/~govind/NHC-07/final/ExceptionsSlides.pdf

On Monday, 12 January 2015 at 13:33:40 UTC, John Colvin wrote:
> On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote:
>> On 1/12/2015 3:02 AM, Tobias Pankrath wrote:
>>> As far as I understand is, it requires each component to settle on the same
>>> discriminated union that packs the error and result, which he calles Result but
>>> is usually Choice in F#.
>>>
>>> Now in D we use the opDot to chain components, which works since we have UFCS.
>>> In F# there a simply three different opDots: >>, >>= and >=> which take care of
>>> the adaption.
>>
>> Or we could just use exceptions, which require none of that.
>
> Interesting little rant about exceptions (and more), from the author of a large and successful project in C++     http://250bpm.com/blog:4

Exception in C++ is different. It is full of pitfalls and generally a usability disaster. I can understand that C++ dev do not like exception, but that say more about C++ than it does about exceptions.

On Monday, 12 January 2015 at 20:07:17 UTC, deadalnix wrote:
> On Sunday, 11 January 2015 at 13:06:27 UTC, Dicebot wrote:
>> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
>
> Rust has an approach very similar to exception, but they do not unwind and trash the whole task instead. Under the hood, it is exception, but tend to be faster as you don't go through the landing pad/personality function dance, but do not fundamentally differ.
>
> The second approach is to pack the result in some kind of object that require checking (but you often don't have anything meaningful to do on failure where you need to check) or propagate the wrapper, à la maybe monad, and get rid of the wrapper where you know what to do on error.
>
> These approach tend to be faster while keeping safety, but requiring more work from the dev. They make sense if the error is common, but are not pulling their weight for very rare failure scenarios like disc running out of space.

Exceptions in Rust are more like Errors in D (but they terminate tasks, not the process!), Result wrapper seems to be standard approach for tasks D uses exceptions for, thus my original question.

On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote:
>>> Does this mean that D will get fast EH?
>>
>>
>> It is fast already...
>
> What makes you say that? Doesn't D still use the standard zero-cost EH that was created for Itanium, where you take the performance hit on unwinding?

LDC, GDC and SDC do all use this.

On 1/12/2015 10:06 AM, Tobias Müller wrote:
On Mon, Jan 12, 2015 at 05:22:26PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> Yeah, exceptions are supposed to be ... well, *exceptions*, rather than
>> the norm. :-) If you're using exceptions to do flow control, you're
>> doing something wrong.
>
> But what's exceptional for you is normal for me.

It's not a subjective truth, it's an objective fact.

If code is throwing exceptions as part of its normal operation, it is designed wrong.

And yes, if you take that as a challenge to try and concoct a counterexample, the point still stands :-)

On 1/12/2015 11:30 AM, Russel Winder via Digitalmars-d wrote:
> Go has an interesting solution, key lookup in a map return a pair
> (result, ok), if lookup succeeded then result is the associated value,
> if ok is false then result is undefined. I quite like this.


That's just putting the responsibility of array bounds checking on the caller.

Would you want (result, ok) returned every time you indexed an array? I sure wouldn't. An associative array isn't conceptually any different.

On 1/12/2015 10:11 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> There are plenty of situations where exceptions used for retries is the most
> sensible solution. Heck, that's even how x86 floating point exceptions work.
> There are plenty of situations where returning state with exceptions makes the
> most sense, e.g. a web service request handler.

I've never encountered any IEEE FP code that ever, and I mean ever, checked the 'exception' sticky flag that IEEE operations require.

Outside of a FP test suite, that is.

Nobody has ever turned on the FP hardware exception faults, either.

Bringing up IEEE 754 FP exceptions as an example of it being "done right" when it is a complete failure severely damages your case.

On 1/12/2015 11:27 AM, Russel Winder via Digitalmars-d wrote:
> Unless you are writing Python code.


Nobody would be in this forum if we preferred Python :-)