On Thursday, 11 June 2015 at 20:44:52 UTC, Ola Fosheim Grøstad wrote:
> Nono, the 80's was more like this:
>
> https://youtu.be/Az_GCJnXAI0
> https://youtu.be/PN7dd2fW3OQ
> https://youtu.be/Ug8WeZyTxXg
> https://youtu.be/drGeLouMm6s

Ouch, guess will stick with modern art -_-

> He is saying that now anything that throws will not only be slow but also have the same limitations as returned errors.

"nothrow by default is combining the slowness of exceptions with
the limitness of returned errors."

He literally said combine the slowness of exceptions. So I don't
know how to read that other than he said it's slow. But perhaps I
am just misunderstanding his wording, so perhaps it's best I just
assume I misunderstood him.

> but also have the same limitations as returned errors

That is a legitimate concern, but I don't think it is correct.
The transitive nature would enforce that you at least handle it
at some point along the chain. Nothing would force you to handle
it right away. Although I think in most cases it's far better to
do it when the error occurs(but this is my style). But when you
don't there would be at least a flag saying "this might fail"
that you and others could see. You can ignore that all the way up
the turtles, but at some point you are going to be like "I should
handle these errors".

> If you have to acknowledge it anyways, then might as well just use returned errors because they are faster.

I guess you could think of nothrow as an acknowledgement. I'd
view it more like a warning to others. As I said before, I don't
think you should be *forced* to do anything. Handle it right away
and you don't have to mark your own function as 'throw'. Don't
handle it, then your function should be marked 'throw', and the
compiler can help others out and tell them to expect to have to
handle the exception at some point.

In regards to being faster, I'm not a big fan of exceptions in
the first place. This probably explains my perspective on them,
but I am familiar with their typical use case. And it's to
communicate errors. I'd much prefer something like what Andrei
presented during one of his C++ talks (Expected<T>). If I were to
design a language today, I might try to incorporate that somehow
with some semantic sugar and a "handle by default" mentality.

On Thursday, 11 June 2015 at 21:57:36 UTC, Dave wrote:

> assume I misunderstood him.

Yeah, its whatever, maybe I am misunderstanding him and your original interpretation is correct.

> That is a legitimate concern, but I don't think it is correct.
> The transitive nature would enforce that you at least handle it
> at some point along the chain. Nothing would force you to handle
> it right away.

I think the sticky point is where this starts to hit virtual functions, function pointers, delegates and the such as its not really known if they are going to throw or not. You basically have to assume that they will throw which means annotating a lot of code that you didn't have to before.

> I guess you could think of nothrow as an acknowledgement. I'd
> view it more like a warning to others. As I said before, I don't
> think you should be *forced* to do anything. Handle it right away
> and you don't have to mark your own function as 'throw'. Don't
> handle it, then your function should be marked 'throw', and the
> compiler can help others out and tell them to expect to have to
> handle the exception at some point.

Personally I would get annoyed by that because now I would have to go though and mark almost all of my code as throw. I strongly dislike having to add a bunch of annotations to my code just to get it to work.

I get that warning others is a good thing, but its also not necessary. Personally I would prefer something like that to be a tool, some one mentioned IDE's that can display what exceptions could be thrown, I think that would be nifty without bogging my code down with a bunch of annotations. Though the list it displays may be incomplete due to function pointers and such.

On Thursday, 11 June 2015 at 20:44:52 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 June 2015 at 20:14:24 UTC, Kagamin wrote:
>> On Thursday, 11 June 2015 at 16:14:46 UTC, Nick Sabalausky wrote:
>> https://youtu.be/VjNVPO8ff84 :3
>> https://youtu.be/bJDY5zTiWUk maybe this too(?)
>
> Nono, the 80's was more like this:
>
> https://youtu.be/Az_GCJnXAI0
> https://youtu.be/PN7dd2fW3OQ
> https://youtu.be/Ug8WeZyTxXg
> https://youtu.be/drGeLouMm6s

Here is a nice documentary about the 80s : https://www.youtube.com/watch?v=bS5P_LAqiVg

On 6/11/2015 3:52 AM, Chris wrote:
> https://www.youtube.com/watch?v=AYMAtbq0bjY
>
> (God, I'm so old!) :-)

There's no business like compiler business:

https://www.youtube.com/watch?v=inzhNkQENOs

I'm in the compiler business:

https://www.youtube.com/watch?v=DwIyClDuBgo

On 6/11/2015 6:40 AM, Dave wrote:
> I believe handling errors with scope
> literally translates to try\catch blocks behind the scenes.

Yes, exactly.

On Thursday, 11 June 2015 at 21:57:36 UTC, Dave wrote:
> In regards to being faster, I'm not a big fan of exceptions in
> the first place. This probably explains my perspective on them,
> but I am familiar with their typical use case. And it's to
> communicate errors. I'd much prefer something like what Andrei
> presented during one of his C++ talks (Expected<T>). If I were to
> design a language today, I might try to incorporate that somehow
> with some semantic sugar and a "handle by default" mentality.

I've reordered your post a bit so I can refer to this part first. I think you and I refer to different things when we talk about returned errors, and with the definition I think you have in mind I do see how my arguments can look like the mumbling of a madman. So I'm going to clear it out first.

At a previous post here(http://forum.dlang.org/post/riiuqazmqfyftppmxxgz@forum.dlang.org), I've said that "I'm not talking about C style return-error-code-and-write-the-actual-result-into-a-variable-passed-by-reference - functional languages like Haskell, Scala and Rust have shown that monadic sum types of result/error are both safe(...) and easy to use(...)"

What I refer by "monadic sum types of result/error" is pretty similar in concept to Expected<T>, though what I in mind is much closer to what functional languages have, which makes allows both easier handling inside expressions and a guarantee that the underlying result will only be used in a path where it was checked that there is no error or after the user explicitly said it's OK to convert it to an exception.

This is what's done in Rust(except it's converted to panics, which are harder to log and contain than exceptions), it can be done in D, and of course a new language that chooses this approach can have syntax for it. Here is an example for how it would be used in D:

    Expected!int parseInt(string txt) {
        if (/*parsing successful*/) {
            return expected(parsedValue);
        } else {
            return error();
        }
    }

    // Propogation - functional style
    Expected!string formatNextValueText(string origNumber) {
        return parseInt(origNumber).ifOK!(
            // good path
            parsedValue => "After %s comes %s".format(
                parsedValue, parsedValue + 1).expected,
            // error path
            () => error());
    }

    // Propogation - imperative style
    Expected!string formatNextValueText(string origNumber) {
        auto parsedValue = parseInt(origNumber);
        if (auto parsedValuePtr = parsedValue.getIfOK()) {
            return "After %s comes %s".format(
                *parsedValuePtr, *parsedValuePtr + 1).expected,
        } else {
            return error();
        }
    }

    // Convertion to exception
    string formatNextValueText(string origNumber) {
        // This will throw an exception if the parsing, and
        // return the parsed value if it succeeded:
        auto parsedValue = parseInt(origNumber).enforceOK();
        return "After %s comes %s".format(
            *parsedValue, *parsedValue + 1);
    }


Now to answer the rest of your post, which actually came first:

>> He is saying that now anything that throws will not only be slow but also have the same limitations as returned errors.
>
> "nothrow by default is combining the slowness of exceptions with
> the limitness of returned errors."
>
> He literally said combine the slowness of exceptions. So I don't
> know how to read that other than he said it's slow. But perhaps I
> am just misunderstanding his wording, so perhaps it's best I just
> assume I misunderstood him.

I also literally said "with the limitness of returned errors.". That part is important part of the sentence. My point is that the exception mechanism is much less limited from the returned value mechanism, because it lets you handler the error in a higher level without modifying the middle levels to acknowledge it. The price for this is slowness.

The benefits of nothrow by default come naturally with returned errors - the users can't implicitly ignore them, and since the possible errors are encoded into the return type any tool that can display the return type can show you these errors.

With nothrow by default, you are paying the performance price of an exception mechanism, and then do extra work to add to it the limitations of returned errors, just so you can get the benefits that come naturally with returned errors. Wouldn't it be better to just use returned errors in the first place?

>> but also have the same limitations as returned errors
>
> That is a legitimate concern, but I don't think it is correct.
> The transitive nature would enforce that you at least handle it
> at some point along the chain. Nothing would force you to handle
> it right away. Although I think in most cases it's far better to
> do it when the error occurs(but this is my style). But when you
> don't there would be at least a flag saying "this might fail"
> that you and others could see. You can ignore that all the way up
> the turtles, but at some point you are going to be like "I should
> handle these errors".
>
>> If you have to acknowledge it anyways, then might as well just use returned errors because they are faster.
>
> I guess you could think of nothrow as an acknowledgement. I'd
> view it more like a warning to others. As I said before, I don't
> think you should be *forced* to do anything. Handle it right away
> and you don't have to mark your own function as 'throw'. Don't
> handle it, then your function should be marked 'throw', and the
> compiler can help others out and tell them to expect to have to
> handle the exception at some point.

This is not very different than returned errors: you either handle the error or change the function's signature so it can pass the error to it's caller.

The big benefit of unchecked exceptions is that they require minimal effort to use - when I code and encounter a path that you can't handle, I just throw an exception(I can also use helper assert/enforce functions). I don't need to interrupt the flow and start adding `throws` all over the project, making my brain do a "context switch" that makes me forget the immediate thing I was working on, and increasing the chances of my commit conflicting with other concurrent commits(because it was touching general functions all over the place). No - I throw the exception, and leave worrying to how it will be handled to later.

The alternative is not that I leave my current task to implement something that'll handle the exception at the right place - the alternative is that I continue my current task without throwing the exception, and only deal with it later on when something crashes or doesn't work properly.

Why? Because I have a task to do, and if every time I encounter a place that *might* indicate an error I'll need to make sure that error is handled, I won't be able to focus on the actual task.

Out of the unhandled error possibilities, exceptions are easiest to fix when they do happen. Forbidding unchecked exceptions doesn't mean there are no errors - just that you don't have this amazing mechanism for tracking and debugging them.

On 6/10/2015 12:56 PM, Russel Winder via Digitalmars-d wrote:
> Please note, OED (which is the definition of the English language
> whatever any USA upstarts may try to pretend) is gearing up to define
> "they" as both singular and plural, thus at a stroke solving all the
> he/she, she/he, (s)he, it faffing.

Hmm, so instead of the documenting the language now the OED is trying to invent it? Such cheek! :-)

On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:
> Please note, OED (which is the definition of the English language
> whatever any USA upstarts may try to pretend)

Glad to hear it. Please tell your countrymen to prefer the '-ize' suffix, as we colonials do, to the '-ise' one, which is a French affectation.

http://en.wikipedia.org/wiki/Oxford_spelling

It should be noted that functional languages that utilize monads
often make you consider the exceptional case, and this is
enforced by the compiler (sound familiar?)

> I also literally said "with the limitness of returned errors.". That part is important part of the sentence. My point is that the exception mechanism is much less limited from the returned value mechanism, because it lets you handler the error in a higher level without modifying the middle levels to acknowledge it. The price for this is slowness.
>
> The benefits of nothrow by default come naturally with returned errors - the users can't implicitly ignore them, and since the possible errors are encoded into the return type any tool that can display the return type can show you these errors.
>
> With nothrow by default, you are paying the performance price of an exception mechanism, and then do extra work to add to it the limitations of returned errors, just so you can get the benefits that come naturally with returned errors. Wouldn't it be better to just use returned errors in the first place?

Perhaps I am missing something big, but I don't see the
performance price that is being paid with nothrow as an
annotation nor as a default. Even with your explanation. No throw
means no throw. No expensive exception mechanism is used. You can
still return whatever you want. You are just guaranteeing no
exceptions.

> This is not very different than returned errors: you either handle the error or change the function's signature so it can pass the error to it's caller.

I agree for the most part on this.

> The big benefit of unchecked exceptions is that they require minimal effort to use - when I code and encounter a path that you can't handle, I just throw an exception(I can also use helper assert/enforce functions). I don't need to interrupt the flow and start adding `throws` all over the project, making my brain do a "context switch" that makes me forget the immediate thing I was working on, and increasing the chances of my commit conflicting with other concurrent commits(because it was touching general functions all over the place). No - I throw the exception, and leave worrying to how it will be handled to later.

The one issues with returned errors is unless you wrap it up in
something like Expected<T> or a specialized struct of some sort,
you can only return one thing in many languages. Even if the
language supports a tuple syntax, in the desired case (where
things work as expected) you return information that is unneeded
(the error). This is something that the Expected<T> object
considers. I'd say this is where exceptions are beneficial (not
the fact that you can throw them and not worry about them),
because you only pay the price when needed, at the expense of
some overhead with the exception handler and the code slowing on
the exceptional path. Take as a counter example of Go which uses
multiple return values to inform users of errors, you get
information that is only useful sometimes.

> The alternative is not that I leave my current task to implement something that'll handle the exception at the right place - the alternative is that I continue my current task without throwing the exception, and only deal with it later on when something crashes or doesn't work properly.
>
> Why? Because I have a task to do, and if every time I encounter a place that *might* indicate an error I'll need to make sure that error is handled, I won't be able to focus on the actual task.

Dealing with the exceptional case should be "part" of the task.
It may be boring, but that is how you write solid code. Because
if your sequence of logic requires Parse() to succeed to get a
result to pass into B(), but Parse() fails, continuing on and
using B() may cause issues. Now throwing an exception is really
useful in this case because you guarantee that you aren't going
to do B with undefined data or defaulted data. However, unless it
is clear, people may not know they need to catch an exception.
Thus the exception propagates up to the top and we now have a
problem.

So now imagine a call server where we have multiple processes
each handling thousands of calls. A call comes in and during the
processing of the call an error occurred and an exception is
thrown. Now if you catch the exception at it's source, no
problem. You can just log that something unexpected happen and
not accept that specific call. If you don't handle the exception
and it manages to escape to the top of the process, bye bye to
all those calls rather than just one. You now have thousands of
upset customers rather than one.

If you are using returned errors and you ignore the error for
some reason and continue on with the process and try to use a
pointer that you expected to be set by a function in which you
didn't check the error for, bye bye thousands of calls (if your
lucky...). Long story short. Respect your errors.

You can often get away with not catching exceptions in UI code,
because often times the UI code intercepts the exception at an
upper level and prints out an error in a window or something.
This becomes trickier in server code.

> Out of the unhandled error possibilities, exceptions are easiest to fix when they do happen. Forbidding unchecked exceptions doesn't mean there are no errors - just that you don't have this amazing mechanism for tracking and debugging them.

Why have unhandled errors in the first place? Design this problem
away.