On Wednesday, 10 June 2015 at 19:56:00 UTC, Dave wrote:
>> I usually agree that the more restrictive option should be the default, but exceptions is... well... the exception. The whole point of the exceptions system is to limit the number of points where you need to worry about something going wrong to the place where it happens and the places where you want to do something special with it.
>
> The point of exceptions is to communicate errors and where they
> originate. As long as this is respected, then I am not following
> your complaint.
>
>> you have to care about the exception at every single point in between.
>
> That's the point. If you don't annotate the function (with a
> throw keyword for instance), then you are forced to catch and
> handle the exception. If you annotate it (saying this function will throw), no catch is needed, but at least you are communicating to the next layer that
> this code *does* have errors that should be accounted for.
>
>> nothrow by default means you can't do that
>
> Actually no guarantees by default means you can't do what I explained above.

The promise of exceptions isn't to not have to specifically handle errors in every layer - it's to not care about exceptions in every layer. I don't want to pass the annotation in each and every intermediate layer - I want only the throwing layer and the catching layer to acknowledge the exception's existence. The middle layers should be written like there is no exception, and when there is one, they will simply fail and let RAII to automatically do the cleanup.

I've programmed enough Java to know how harmful nothrow-by-default is. It doesn't really guarantee the functions not annotated as throwing won't crash - only that if they do crash there is nothing you can do about it. This mechanism is so easy to bypass in harmful ways(catch and rethrow something that doesn't need annotation(like Error), or terminate the process with a special exit function), and annotating the layers all the way up is so cumbersome(and sometimes impossible - when you override functions, or pass delegates) that this mechanism tends to encourage to bypass it, which harms the debugging.

Of course, nothrow as the optional annotation is a different syntax for the same semantics, so it suffers from the same drawbacks but it has the benefit of seldom being use therefore seldom getting in your way. Which leads me to the final conclusion - there shouldn't be nothrow, not by default and not as special annotation!

(I'm not talking about D here - this isn't worth the code breakage - but generally on programming languages)

If it's an error that the caller needs to know about - make it part of the return type. If it doesn't need to know about it - throw an exception and let someone up the line handle it. Rust got it right - though they made it a bit cumbersome to catch `panic`s. Why would I need to catch panic? To display them nicely to the user(don't just dump to stderr - pop up a window that apologizes and prompts the user to email the exception data to the developers) or to rollback the changes(yes, there was an irrecoverable error in the program. That doesn't give me the right to corrupt user data when I can avoid it). But the point is - you can either handle it or ignore it. The "sign here and we'll pass it on" bureaucracy is not benefiting anyone.

On Wednesday, 10 June 2015 at 18:06:16 UTC, Andrei Alexandrescu wrote:
> On 6/10/15 10:54 AM, Brian Rogoff wrote:
>> The Rust community is probably the absolute best because tolerance for
>> that is near zero. Too much I think, but perhaps they're right and it's
>> for the best.
>
> I'm glad to notice the tone of posts here, say, after DConf has improved substantially. -- Andrei

*sigh* Indeed. Some of the posts do seem to be too confrontational lately. But it'll probably blow over like it usually does. It would be nice though if we stayed civil around here.

- Jonathan M Davis

On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:
> One big difference between the D community and other languages' communities is is that D people keep criticizing the language and see every little flaw in every little corner, which is good and which is why D is the way it is. Other languages' communities are more like "This is theeeeeee language of the future, it's super-duper, no question asked, none permitted either!"

Yes, I have not seen a better community than that. It's awesome!

> The promise of exceptions isn't to not have to specifically handle errors in every layer

Correct me if I am wrong, but aren't exceptions in D used for
general error handling? Doesn't Phobos prefer exceptions over
return codes?

> it's to not care about exceptions in every layer.

My second job was working in the sustaining department of a large
company. One of the most frequent cause of bugs were people not
checking errors. The fix was almost always handle the error at
its source and log or signal a message to some IO informing the
user. Users tend to prefer messages over complete meltdowns. Too
many avoidable outages and crashes came by my desk due to this
attitude. Very few domains/cases require hard fails.

> I don't want to pass the annotation in each and every intermediate layer

Seems like an odd comment to have on the forum of a language that
frequently has functions in the standard library annotated like
this:
pure nothrow @nogc @safe real abs(Num)(Num y)

> The middle layers should be written like there is no exception, and when there is one, they will simply fail and let RAII to automatically do the cleanup.

Everything works better than expect...

> I've programmed enough Java to know how harmful nothrow-by-default is.

I disagree one this. Lets agree to disagree.

> It doesn't really guarantee the functions not annotated as throwing won't > crash

Combined with other guarantees (such as immutability, thread
local storage, safe memory management, side-effect free code, no
recursion, etc), you can make a reasonable guarantee about the
safety of your code.

> Of course, nothrow as the optional annotation is a different syntax for the same semantics, so it suffers from the same drawbacks but it has the benefit of seldom being use therefore seldom getting in your way. Which leads me to the final conclusion - there shouldn't be nothrow, not by default and not as special annotation!

The guarantee is useful in many cases. Again lets agree to
disagree. But I agree most people will "opt-out".

> (I'm not talking about D here - this isn't worth the code breakage - but generally on programming languages)

As am I. My initial comment was not meant to encourage change in
the D language. But perhaps it may spin the right dials on
someone else and they may think of a better fitting solution.

> If it's an error that the caller needs to know about - make it part of the return type. If it doesn't need to know about it - throw an exception and let someone up the line handle it.

I don't agree with this. Too much to worry about. Impractical to
maintain both paradigms. What errors don't you need to know about?

> Rust got it right - though they made it a bit cumbersome to catch `panic`s. Why would I need to catch panic? To display them nicely to the user(don't just dump to stderr - pop up a window that apologizes and prompts the user to email the exception data to the developers) or to rollback the changes(yes, there was an irrecoverable error in the program.

I am not anywhere near proficient enough in Rust to really
comment much on it's methods.

> handle it or ignore it.

The process I mentioned would not prevent this in anyway. Just
inform others of the decision you made that may have adverse
effects on the stability of their code.

On Wednesday, 10 June 2015 at 19:57:15 UTC, Russel Winder wrote:
> Please note, OED (which is the definition of the English language

OED is a reflection(an approximate one at that) of what the English language is, not the definition.

On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky wrote:
> Contrary to technical official definition, in REAL WORLD usage, "he" is BOTH a masuline AND a gender-neutral pronoun. A few occasional nutbags who deliberately ignore the "gender-neutral" possibility in order to promote their "you are all sexists" agenda is NO excuse for bowing to thier pressure.

Personally I don't perceive he as ever being gender neutral(us native speaker). If I am trying to be gender neutral then I will use "they" or "that person" or "one". If some one did try to use he in a gender neutral context then I think it would sound weird to me.

On Thursday, 11 June 2015 at 00:57:34 UTC, Tofu Ninja wrote:
> On Wednesday, 10 June 2015 at 20:14:10 UTC, Nick Sabalausky wrote:
>> Contrary to technical official definition, in REAL WORLD usage, "he" is BOTH a masuline AND a gender-neutral pronoun. A few occasional nutbags who deliberately ignore the "gender-neutral" possibility in order to promote their "you are all sexists" agenda is NO excuse for bowing to thier pressure.
>
> Personally I don't perceive he as ever being gender neutral(us native speaker). If I am trying to be gender neutral then I will use "they" or "that person" or "one". If some one did try to use he in a gender neutral context then I think it would sound weird to me.

'he' has been a gender neutral pronoun for centuries, and as far as I'm aware this has its roots in latin using 'man'(vir?) as a gender neutral pronoun.

On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote:
> 'he' has been a gender neutral pronoun for centuries, and as far as I'm aware this has its roots in latin using 'man'(vir?) as a gender neutral pronoun.

I am just saying that personally it sounds odd to me to use it that way and I don't hear people use it that way either. In gender neutral contexts where you don't know the gender I almost always say/hear they/their. Maybe he losing its gender neutrality is a recent thing, I don't know. Maybe its just a thing with mid-westerners?

On 11/06/2015 3:37 a.m., Chris wrote:
> On Wednesday, 10 June 2015 at 14:29:51 UTC, Thiez wrote:
>> On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:
>>> One big difference between the D community and other languages'
>>> communities is is that D people keep criticizing the language and see
>>> every little flaw in every little corner, which is good and which is
>>> why D is the way it is.
>>
>> Or perhaps D simply has more flaws to criticize.
>
> How can you tell that e.g. Nim has less flaws when it's still so young?
> It's too early to tell.
>
>> On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote:
>>> Other languages' communities are more like "This is theeeeeee
>>> language of the future, it's super-duper, no question asked,
>>> none permitted either!"
>>
>> Perhaps you are depicting other communities as a bunch of group-think
>> hipsters because you are insecure about your own community?
>>
>> Look, I can make baseless accusations too. Wouldn't you agree it would
>> be nicer (and more effective, I imagine) to promote your community by
>> calling attention rather to its positive qualities, rather than
>> demonizing other communities? Especially when your negative portrayals
>> of other communities are not accompanied by any evidence?
>>
>> I'm sure you're a smart person and will for each of the communities in
>> question be able to find evidence of at least one person who at some
>> point in time acted in the way you suggested. Of course such a thing
>> would not prove that the behaviour is representative of the community,
>> so please don't.
>
> I've been following post-C(++) programming languages for quite a while
> now. Back in the day Java was a big thing, and Python was also hip. Then
> we had Ruby and whatnot. The base line would always be "it's a cool
> language, it's the future" and flaws would hardly ever be mentioned,
> critical voices silenced. All the benchmarking tricks used by the Java
> community to make people believe it's as fast as native code - while you
> know from your own experience that it's not - are just one example. Ah,
> and there was Ajax, remember? How's jQuery doing, by the way? I've used
> some of these technologies and none of them would live up to my
> expectations. But the pattern is always the same "It's theeee thing,
> wow, a must-have!" Sorry, but whenever I hear a language is (almost)
> perfect and theee way to go, I grow suspicious. If all communities are
> as critical as D's, why then do we have so much mediocre technology out
> there?
>
> I am interested in Nim and welcome it. But it's too early to say whether
> it's good or mediocre. I wonder, though, when you look Nim up on
> Wikipedia it states:
>
> Influenced by
> Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon
>
> Did they really never get any inspiration from D?? I wonder. Seems a bit
> odd, but well.

The biggest difference between the D community in general and other communities is actually quite simple.

Experience.

That's right. As mentioned we accept bugs, we accept issues. Discuss them at length and fix them when a good solution is found. Not only that but we look for problems to fix.
This is the mentality of a good software engineer. One who doesn't care about their own pride or ego but genuinely wants to make good code.

In a lot of ways this makes us the best developers on the planet. It would explain a lot, including how other language communities snob us yet we look at them for ideas.

Just a thought.

On 2015-06-10 18:34, Joakim wrote:

> May still be possible, Apple just announced that the default format to
> submit apps for iOS will be bitcode from now on, which people are
> speculating is some form of llvm bitcode:

I'm pretty sure they mentioned it was LLVM IR on the "Platform, State of the Union" talk.

-- 
/Jacob Carlborg