On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:
> On Wednesday, 10 June 2015 at 17:34:55 UTC, jmh530 wrote:
>> 3) Immutability by default. Someone (somewhere) made an interesting point that it can be conceptually convenient to have the most restrictive choice as the default. I'm not sure I agree with that (maybe the most common choice used in good code), but at least immutability by default it can be helpful for concurrent programming.
>
> I am one of those that think that a language should allow you to
> do whatever you want, but be restrictive by default. For example
> immutability unless you explicitly ask for mutability (like in
> Rust). D sort of has the ability to do this, but it's sort of
> backwards due to it's defaults. For instance D is mutable by
> default (an inherited trait due to the C subset of the language),
> with the ability to explicitly mark values as immutable. Another
> backwards annotation is nothrow. I don't really care if something
> doesn't throw, I care when it throws, because then I have to do
> something (or my program may crash unexpectedly). Even if the
> enforcement is kind of there (although unannotated functions can
> do whatever), it would have been a better guarantee to disallow
> this by default.

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. nothrow by default means you can't do that - you have to care about the exception at every single point in between. The result is a better syntax for the exact same thing the exceptions idiom was supposed to prevent...

> 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.

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.

On Wed, 2015-06-10 at 19:05 +0000, via Digitalmars-d wrote:
> On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote:
> > That's actually a good idea, you might not have noticed it, but I rarely use "he" alone as a general term and I notice it when other people do. Little things like this in language can make a difference in people's feelings and cause discomfort in the environment.
> 
> Sure, follow your own ethics, but that won't work in an international environment as a rule without coming off as censorship. You cannot force people globally to follow a local culture. I also try to cut down on the term "you" as a general term since people might think I mean them personally.
> 
> At some point you just have question intent if there is a misunderstanding, rather than control every expression or else everything becomes "it":
> 
> "A bad programmer create bugs when it edits its files...".
> 
> And if people force you to write "it", it is quite reasonable to wonder what else they strongly object to so you better just stay silent. I really do try to cut down on the term "you"?
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 6/10/15 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.

Is they out of its mind? :)

On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote:
> On Wednesday, 10 June 2015 at 18:18:55 UTC, Ola Fosheim Grøstad wrote:
>> It's always a good idea to not go personal, but I think they overdo it when you're not allowed to write "he" as a general term because it is gender specific.
>
> That's actually a good idea, you might not have noticed it, but I rarely use "he" alone as a general term and I notice it when other people do. Little things like this in language can make a difference in people's feelings and cause discomfort in the environment.

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.

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!"

spot on!

On Wednesday, 10 June 2015 at 19:05:15 UTC, Ola Fosheim Grøstad wrote:
> Sure, follow your own ethics, but that won't work in an international environment as a rule without coming off as censorship. You cannot force people globally to follow a local culture.

True, and a question of balance.  A little bit of mutual adjustment goes a long way.

> I also try to cut down on the term "you" as a general term since people might think I mean them personally.

That's what 'one' (rather than 'you') is for.  But if one uses the word 'one' in this context it comes off as archaic and elitist.  So be it.

> "A bad programmer create bugs when it edits its files...".
>
> And if people force you to write "it", it is quite reasonable to wonder what else they strongly object to so you better just stay silent. I really do try to cut down on the term "you"?

Quite!

On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:

>
> Just a thought from a random spectator ;)

Interesting perspective. While I find the plethora of keywords in D a tad confusing (nowhere near as confusing as rust's borrowing!), I'm not sure it would necessarily mean that D would be discarded in favor of something else. There's a lot to like about D as a language.

More generally, it's a question of what paradigm you are trying to enforce. I think your paradigm is really about minimizing bugs, rather than necessarily wanting restriction. Nevertheless, I'm sure there are many who agree. My preference is a bit simpler: I want to write good code without a lot of clutter. So I think that the default option should be whatever enforces that. I don't see a reason why you should have a whole string of keywords before every function. Anything that simplifies that is a positive to me.

To your grepable point, another alternative is that you allow the annotations in either case so you could have a throw keyword and a nothrow keyword. If nothrow is default, you could still put it in there and then grep to change it to throw later. For that matter, it might be interesting to have some way to specify the default behavior for each .d file.

On Wednesday, 10 June 2015 at 21:09:23 UTC, jmh530 wrote:
> On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:
>
>>
>> Just a thought from a random spectator ;)
>
> Interesting perspective. While I find the plethora of keywords in D a tad confusing (nowhere near as confusing as rust's borrowing!),

I won't try to defend Rust's syntax (and they certainly don't let
you opt out of a whole lot).

> I'm not sure it would necessarily mean that D would be discarded in favor of something else. There's a lot to like about D as a language.

If that something is more favorable why would they not? Only
answers to that is stubbornness and resistance to change ;)

> More generally, it's a question of what paradigm you are trying to enforce. I think your paradigm is really about minimizing bugs, rather than necessarily wanting restriction.

If someone wants to annotate @system and do all the dirty things
they want. So be it. At least others that use their code
(assuming transitiveness) knows that they are doing it.

> Nevertheless, I'm sure there are many who agree. My preference is a bit simpler: I want to write good code without a lot of clutter. So I think that the default option should be whatever enforces that. I don't see a reason why you should have a whole string of keywords before every function.

That would depend on the syntax of the language mostly. I'm sure
if designed well, you could avoid unnecessary "clutter". Maybe by
allow people to define their own attributes that can be used in
place of many attributes (as long as it is easy to look it up).

> To your grepable point, another alternative is that you allow the annotations in either case so you could have a throw keyword and a nothrow keyword.

Problem with "opt-in" constructs, is if people don't have to they
generally "opt-out". So expect the default to be the most common.
You might get library writers writing idiomatically, but I
wouldn't expect it from an application development side. Adding
an extra keyword per function is probably not that big of a deal
in the long run. Especially if it prevents code.

All of this is kind of late for D. Waaaay too many breaking changes. But maybe something for D3...;)

> There's a lot to like about D as a language.

Agreed.