Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

https://news.ycombinator.com/newest (search that page, if not found 
click "More" and search again)

https://www.facebook.com/dlang.org/posts/855022447844771

https://twitter.com/D_Programming/status/471330026168651777


Andrei

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 5/27/2014 12:42 PM, Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/


 https://news.ycombinator.com/newest (search that page, if not found
 click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777


 Andrei

What? Andrei's keynote isn't first? :(

Nonetheless, this Scott Meyers talk is fantastic (and a good choice for 
"first released").

Only one thing could've made this better: When the MC finishes his 
intro, there should be some heavy rock music and laser lights while 
Scott comes up on stage. :)  Oh well, maybe next year...Who's got the 
fog machine?

"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:

On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

Thanks, is it possible to put it on Youtube as well? Ustream 
stutters every second from where I am which makes me feel sorry 
for the speaker…

"Mattcoder" <fromtheotherside mail.com> writes:

Great, but I think this should be on youtube too, reasons for 
this is the possibility to change resolution and other features 
like subtitles for foreigners etc.

Matheus.

Johannes Totz <johannes jo-t.de> writes:

On 27/05/2014 18:43, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 
 Thanks, is it possible to put it on Youtube as well? Ustream stutters
 every second from where I am which makes me feel sorry for the speaker…

http://rg3.github.io/youtube-dl/ helps with the stutter.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 5/27/2014 6:10 PM, Johannes Totz wrote:
 On 27/05/2014 18:43, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 Thanks, is it possible to put it on Youtube as well? Ustream stutters
 every second from where I am which makes me feel sorry for the speaker…

 http://rg3.github.io/youtube-dl/ helps with the stutter.

Or this FF extension (which is what I normally use):

http://www.downloadhelper.net/

"John" <john.joyus gmail.com> writes:

On Tuesday, 27 May 2014 at 22:10:02 UTC, Johannes Totz wrote:

 Thanks, is it possible to put it on Youtube as well? Ustream 
 stutters
 every second from where I am which makes me feel sorry for the 
 speaker…

 http://rg3.github.io/youtube-dl/ helps with the stutter.

+1

"w0rp" <devw0rp gmail.com> writes:

That was brilliant. I think Scott made two very good points. D 
needs people like himself to educate others, and that D should 
focus on behaviour which makes sense not only in a particular 
context, but with respect to the other contexts. (Which is what 
C++ lacks greatly.)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Tue, 27 May 2014 14:57:46 -0400, w0rp <devw0rp gmail.com> wrote:

 That was brilliant. I think Scott made two very good points. D needs  
 people like himself to educate others

I think you misunderstood that point ;) He was saying to make D so that we  
DON'T need specialists like himself that can make a career out of  
explaining the strange quirks of D, mostly by not having those quirks in  
the first place.

-Steve

"w0rp" <devw0rp gmail.com> writes:

On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer 
wrote:
 On Tue, 27 May 2014 14:57:46 -0400, w0rp <devw0rp gmail.com> 
 wrote:

 That was brilliant. I think Scott made two very good points. D 
 needs people like himself to educate others

 I think you misunderstood that point ;) He was saying to make D 
 so that we DON'T need specialists like himself that can make a 
 career out of explaining the strange quirks of D, mostly by not 
 having those quirks in the first place.

 -Steve

Oh, I see what he's saying now. The *last* thing. That's... 
confusing use of English. It makes more sense with respect to his 
other comment, though.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Tue, 27 May 2014 16:11:12 -0400, w0rp <devw0rp gmail.com> wrote:

 On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer wrote:
 On Tue, 27 May 2014 14:57:46 -0400, w0rp <devw0rp gmail.com> wrote:

 That was brilliant. I think Scott made two very good points. D needs  
 people like himself to educate others

 I think you misunderstood that point ;) He was saying to make D so that  
 we DON'T need specialists like himself that can make a career out of  
 explaining the strange quirks of D, mostly by not having those quirks  
 in the first place.

 -Steve

 Oh, I see what he's saying now. The *last* thing. That's... confusing  
 use of English.

Yes, it's a common phrase.

http://dictionary.cambridge.org/us/dictionary/british/the-last-thing-you-want-need-etc

Basically it means something you definitely DON'T need.

-Steve

"Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:

On Tuesday, 27 May 2014 at 20:11:13 UTC, w0rp wrote:
 On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer 
 wrote:
 On Tue, 27 May 2014 14:57:46 -0400, w0rp <devw0rp gmail.com> 
 wrote:

 That was brilliant. I think Scott made two very good points. 
 D needs people like himself to educate others

 I think you misunderstood that point ;) He was saying to make 
 D so that we DON'T need specialists like himself that can make 
 a career out of explaining the strange quirks of D, mostly by 
 not having those quirks in the first place.

 -Steve

 Oh, I see what he's saying now. The *last* thing. That's... 
 confusing use of English. It makes more sense with respect to 
 his other comment, though.

Sometimes I think English could use a guy like him.

"w0rp" <devw0rp gmail.com> writes:

On Tuesday, 27 May 2014 at 21:16:34 UTC, Chris Nicholson-Sauls 
wrote:
 On Tuesday, 27 May 2014 at 20:11:13 UTC, w0rp wrote:
 On Tuesday, 27 May 2014 at 19:43:57 UTC, Steven Schveighoffer 
 wrote:
 On Tue, 27 May 2014 14:57:46 -0400, w0rp <devw0rp gmail.com> 
 wrote:

 That was brilliant. I think Scott made two very good points. 
 D needs people like himself to educate others

 I think you misunderstood that point ;) He was saying to make 
 D so that we DON'T need specialists like himself that can 
 make a career out of explaining the strange quirks of D, 
 mostly by not having those quirks in the first place.

 -Steve

 Oh, I see what he's saying now. The *last* thing. That's... 
 confusing use of English. It makes more sense with respect to 
 his other comment, though.

 Sometimes I think English could use a guy like him.

I'm actually a native speaker of 25 years and I didn't get it at 
first. Natural language communicates ideas approximately.

Walter Bright <newshound2 digitalmars.com> writes:

On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at first. Natural
 language communicates ideas approximately.

What bugs me is when people say:

    I could care less.

when they mean:

    I couldn't care less.


and:

    If you think that, you have another thing coming.

when they mean:

    If you think that, you have another think coming.

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it 
 at first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

http://www.youtube.com/watch?v=om7O0MFkmpw&feature=kp

Walter Bright <newshound2 digitalmars.com> writes:

On 5/28/2014 2:28 AM, John Colvin wrote:
 On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

 http://www.youtube.com/watch?v=om7O0MFkmpw&feature=kp

At least the Queen and I agree on something!

"Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:

On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it 
 at first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

Whats wrong with "If you think that, you have another thing 
coming."?

I've always understood it sort of like say your Father saying:

"If you think that [i.e. you can steal your little brother's ice 
cream cone], then  you have another thing [i.e no ice cream, but 
maybe the leather strap] coming."

=?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= via Digitalmars-d-announce writes:

On 2014-05-28 13:05, Craig Dillabaugh via Digitalmars-d-announce wrote:
 On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at
 first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

 Whats wrong with "If you think that, you have another thing coming."?

 I've always understood it sort of like say your Father saying:

 "If you think that [i.e. you can steal your little brother's ice cream
 cone], then  you have another thing [i.e no ice cream, but maybe the
 leather strap] coming."

It's an old saying, and in more modern English might be phrased "If you 
think that, you have another thought coming", i.e. you'll soon enough 
see why you're wrong.

--
   Simen

"safety0ff" <safety0ff.dev gmail.com> writes:

On Wednesday, 28 May 2014 at 13:05:53 UTC, Craig Dillabaugh wrote:
 Whats wrong with "If you think that, you have another thing 
 coming."?

 I've always understood it sort of like say your Father saying:

 "If you think that [i.e. you can steal your little brother's 
 ice cream cone], then  you have another thing [i.e no ice 
 cream, but maybe the leather strap] coming."

I think it depends on the context, "another thing coming" works 
with threats whereas "another think coming" works with 
civilized/intellectual disagreement.

Due to the popularity of "another thing coming" I probably would 
avoid using "think coming" lest it be interpreted as hostility.

Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:

On 28/05/2014 2:05 PM, Craig Dillabaugh wrote:
 On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at
 first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

 Whats wrong with "If you think that, you have another thing coming."?

 I've always understood it sort of like say your Father saying:

 "If you think that [i.e. you can steal your little brother's ice cream
 cone], then  you have another thing [i.e no ice cream, but maybe the
 leather strap] coming."

I couldn't resist looking up this debate, and its quite a fiery one with 
no clear winner! There is no clear origin to the phrase and equal 
arguments for and against both forms.

My personal view is that the thinGists are right, because I often use 
the word believe in the first half, i.e. "if you believe that, then you 
have another thing coming." I wouldn't tell anyone that they had another 
belief coming, as in my experience my opinions have very little impact 
on the beliefs of others.

Also, grammatically speaking, if I was expecting someone to change their 
mind, I like to think that I'd more likely say that they had another 
thought coming, or "If you think that, then you have another thought to 
come." Not because think can never be a noun, I often say "lets have a 
think."

A...

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton  
<alix.DOT.pexton gmail.dot.com> wrote:

 On 28/05/2014 2:05 PM, Craig Dillabaugh wrote:
 On Tuesday, 27 May 2014 at 21:40:00 UTC, Walter Bright wrote:
 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at
 first. Natural
 language communicates ideas approximately.

 What bugs me is when people say:

    I could care less.

 when they mean:

    I couldn't care less.


 and:

    If you think that, you have another thing coming.

 when they mean:

    If you think that, you have another think coming.

 Whats wrong with "If you think that, you have another thing coming."?

 I've always understood it sort of like say your Father saying:

 "If you think that [i.e. you can steal your little brother's ice cream
 cone], then  you have another thing [i.e no ice cream, but maybe the
 leather strap] coming."

 I couldn't resist looking up this debate, and its quite a fiery one with  
 no clear winner! There is no clear origin to the phrase and equal  
 arguments for and against both forms.

If you think I'll let it go you're mad, you got another thing comin'

-Steve

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On 5/29/2014 9:14 AM, Steven Schveighoffer wrote:
 On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton
 <alix.DOT.pexton gmail.dot.com> wrote:
 I couldn't resist looking up this debate, and its quite a fiery one
 with no clear winner! There is no clear origin to the phrase and equal
 arguments for and against both forms.

 If you think I'll let it go you're mad, you got another thing comin'

Heh, I see I'm not the only one who's has that playing in their head 
through this whole conversation ;)

Oddly enough, my mind plays it as the Pat Boone cover (from "In a Metal 
Mood"). His version is surprisingly good.

"Regan Heath" <regan netmail.co.nz> writes:

On Tue, 27 May 2014 22:40:00 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 5/27/2014 2:22 PM, w0rp wrote:
 I'm actually a native speaker of 25 years and I didn't get it at first.  
 Natural
 language communicates ideas approximately.

 What bugs me is when people say:

     I could care less.

I've always assumed some sort of sentence finishing laziness on their  
part.  As in, "I could care less, but it would be pretty hard to do so" or  
something like that.

R

Andrew Edwards <ridimz yahoo.com> writes:

On 5/27/14, 2:57 PM, w0rp wrote:
 That was brilliant. I think Scott made two very good points. D needs
 people like himself to educate others, and that D should focus on
 behaviour which makes sense not only in a particular context, but with
 respect to the other contexts. (Which is what C++ lacks greatly.)

Really? What I got out of it was that D doesn't need people like him 
because his job is to explain the inconsistencies of the language. By 
designing a consistent language in the first place, people can readily 
understand it in all context thereby eliminating the need for people 
like him.

At roughly 04:55 he says:

"I am a professional explainer. That's my job. Who knew that you can 
have a job doing that? Turns out you can actually make a career of it."

He gives a slew of examples of kind of things he's got to explain on a 
daily basis and closes out the whole thing with:

"The message that I bring to the D Community, based on my experience 
with with C++, is that the last thing D needs is somebody like me."

"Brian Schott" <briancschott gmail.com> writes:

On Tuesday, 27 May 2014 at 19:44:01 UTC, Andrew Edwards wrote:
 Really? What I got out of it was that D doesn't need people 
 like him because his job is to explain the inconsistencies of 
 the language. By designing a consistent language in the first 
 place, people can readily understand it in all context thereby 
 eliminating the need for people like him.

Another point is that D is still small enough that we have time 
to fix things before they get out of control.

(One of my favorite parts of this talk is when he points out that 
you need parenthesis in a specific kind of lambda just because 
the committee forgot to update the grammar specification.)

Leandro Lucarella <luca llucax.com.ar> writes:

Brian Schott, el 27 de May a las 20:03 me escribiste:
 On Tuesday, 27 May 2014 at 19:44:01 UTC, Andrew Edwards wrote:
Really? What I got out of it was that D doesn't need people like
him because his job is to explain the inconsistencies of the
language. By designing a consistent language in the first place,
people can readily understand it in all context thereby
eliminating the need for people like him.

 
 Another point is that D is still small enough that we have time to
 fix things before they get out of control.
 
 (One of my favorite parts of this talk is when he points out that
 you need parenthesis in a specific kind of lambda just because the
 committee forgot to update the grammar specification.)

This is very related to Don's message of last year's talk about ROI of
breaking changes.
https://www.youtube.com/watch?v=pmwKRYrfEyY#t=30m55s

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Y serán tiempos de vanos encuentros entre humano y humano; en que las
fieras se comerán entre ellas y después del final; en que se abríran las
tierras y los cielos... y en el medio de la nada Racing saldrá campeón.
	-- Ricardo Vaporeso

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 https://news.ycombinator.com/newest (search that page, if not 
 found click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777


 Andrei

I did a translation of most of the code in the slides.

http://dpaste.dzfl.pl/72b5cfcb72e4

I'm planning to transform it into blog post (or series). Right 
now it just has some scratch notes. Feel free to let me know 
everything I got wrong.

Philippe Sigaud via Digitalmars-d-announce writes:

 I did a translation of most of the code in the slides.

 http://dpaste.dzfl.pl/72b5cfcb72e4

 I'm planning to transform it into blog post (or series). Right now it just
 has some scratch notes. Feel free to let me know everything I got wrong.

That's a good idea. I think most of us did that while listening to the
talk. I kept telling myself: 'oh wait, that'd simpler in D' or 'that
does not exist in D'.

As for the class inheritance problem, I'd also be interested in an answer.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 28 May 2014 at 05:30:18 UTC, Philippe Sigaud via 
Digitalmars-d-announce wrote:
 I did a translation of most of the code in the slides.

 http://dpaste.dzfl.pl/72b5cfcb72e4

 I'm planning to transform it into blog post (or series). Right 
 now it just
 has some scratch notes. Feel free to let me know everything I 
 got wrong.

 That's a good idea. I think most of us did that while listening 
 to the
 talk. I kept telling myself: 'oh wait, that'd simpler in D' or 
 'that
 does not exist in D'.

 As for the class inheritance problem, I'd also be interested in 
 an answer.

When he explained why C++ inferred a const int type as int, he 
tripped me up because D does drop const for value types. But D 
does the simple to explain thing, may not be the expected thing 
(seen questions about it in D.learn), but it is simple to explain.

dennis luehring <dl.soluz gmx.net> writes:

woudl be nice to have some sort of example by example comparison
or as an extension to the page http://dlang.org/cpptod.html

Am 28.05.2014 07:40, schrieb Jesse Phillips:
 On Wednesday, 28 May 2014 at 05:30:18 UTC, Philippe Sigaud via
 Digitalmars-d-announce wrote:
 I did a translation of most of the code in the slides.

 http://dpaste.dzfl.pl/72b5cfcb72e4

 I'm planning to transform it into blog post (or series). Right
 now it just
 has some scratch notes. Feel free to let me know everything I
 got wrong.

 That's a good idea. I think most of us did that while listening
 to the
 talk. I kept telling myself: 'oh wait, that'd simpler in D' or
 'that
 does not exist in D'.

 As for the class inheritance problem, I'd also be interested in
 an answer.

 When he explained why C++ inferred a const int type as int, he
 tripped me up because D does drop const for value types. But D
 does the simple to explain thing, may not be the expected thing
 (seen questions about it in D.learn), but it is simple to explain.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote:
 woudl be nice to have some sort of example by example comparison
 or as an extension to the page http://dlang.org/cpptod.html

I've got two posts complete[1]. Since C++ and D are exactly the 
same for the majority of the code I'm only showing D and talk of 
C++'s choice. While the rules governing D's behavior are fairly 
simple I feel that I've expanded on the content enough to provide 
useful information beyond fixing C++'s problems.

1. http://he-the-great.livejournal.com/52333.html

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/29/14, 9:21 PM, Jesse Phillips wrote:
 On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote:
 woudl be nice to have some sort of example by example comparison
 or as an extension to the page http://dlang.org/cpptod.html

 I've got two posts complete[1]. Since C++ and D are exactly the same for
 the majority of the code I'm only showing D and talk of C++'s choice.
 While the rules governing D's behavior are fairly simple I feel that
 I've expanded on the content enough to provide useful information beyond
 fixing C++'s problems.

 1. http://he-the-great.livejournal.com/52333.html

Nice! I'll post it tomorrow on reddit and friends. You have an unmatched 
brace after "assert(a2[].all!(x => x == 0));".

Andrei

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/30/14, 3:53 AM, Andrei Alexandrescu wrote:
 On 5/29/14, 9:21 PM, Jesse Phillips wrote:
 On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote:
 woudl be nice to have some sort of example by example comparison
 or as an extension to the page http://dlang.org/cpptod.html

 I've got two posts complete[1]. Since C++ and D are exactly the same for
 the majority of the code I'm only showing D and talk of C++'s choice.
 While the rules governing D's behavior are fairly simple I feel that
 I've expanded on the content enough to provide useful information beyond
 fixing C++'s problems.

 1. http://he-the-great.livejournal.com/52333.html

 Nice! I'll post it tomorrow on reddit and friends. You have an unmatched
 brace after "assert(a2[].all!(x => x == 0));".

 Andrei

Actually a bunch of unmatched braces (formatter eats the closing one?) 
and at least one ";;" instead of ";". -- Andrei

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Friday, 30 May 2014 at 10:56:30 UTC, Andrei Alexandrescu wrote:
 Nice! I'll post it tomorrow on reddit and friends. You have an 
 unmatched
 brace after "assert(a2[].all!(x => x == 0));".

 Andrei

 Actually a bunch of unmatched braces (formatter eats the 
 closing one?) and at least one ";;" instead of ";". -- Andrei

It is not unmatched, the whole article is one big program (with 
the exception of the conclusion), the final brace is at the end:

     static int[100] a3;
     assert(a3[].all!(x => x == 0));
}

Though the ;; is just an accident.

"safety0ff" <safety0ff.dev gmail.com> writes:

On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote:
 1. http://he-the-great.livejournal.com/52333.html

Note that in the following code:
     import core.memory : GC;
     int* pxprime = cast(int*)GC.malloc(int.sizeof);
     version(none) assert(pxprime); // possibly zero

GC.malloc currently doesn't initialize the memory if NO_SCAN is 
specified as attribute.
Also, I don't understand why half of your asserts have 
version(none) (it's distracting.)
Also note that you're not dereferencing pxprime, I'm not sure if 
its intentional.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Friday, 30 May 2014 at 11:31:18 UTC, safety0ff wrote:
 On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote:
 1. http://he-the-great.livejournal.com/52333.html

 Note that in the following code:
     import core.memory : GC;
     int* pxprime = cast(int*)GC.malloc(int.sizeof);
     version(none) assert(pxprime); // possibly zero

 GC.malloc currently doesn't initialize the memory if NO_SCAN is 
 specified as attribute.

I expect malloc to not initialize ever, that was the point. 
Initialization can be done with calloc.

 Also, I don't understand why half of your asserts have 
 version(none) (it's distracting.)

I can't guarantee the assert to pass, as the comment mentions it 
is possibly zero, which would cause failure.

 Also note that you're not dereferencing pxprime, I'm not sure 
 if its intentional.

Thanks,  was intending to dereference.

Thank you for feedback.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/29/14, 9:21 PM, Jesse Phillips wrote:
 On Wednesday, 28 May 2014 at 07:21:56 UTC, dennis luehring wrote:
 woudl be nice to have some sort of example by example comparison
 or as an extension to the page http://dlang.org/cpptod.html

 I've got two posts complete[1]. Since C++ and D are exactly the same for
 the majority of the code I'm only showing D and talk of C++'s choice.
 While the rules governing D's behavior are fairly simple I feel that
 I've expanded on the content enough to provide useful information beyond
 fixing C++'s problems.

 1. http://he-the-great.livejournal.com/52333.html

http://www.reddit.com/r/programming/comments/26vy2i/comparing_scott_meyers_talk_examples_in_c_and_d/

Andrei

"Kagamin" <spam here.lot> writes:

On Friday, 30 May 2014 at 04:21:18 UTC, Jesse Phillips wrote:
 I've got two posts complete[1]. Since C++ and D are exactly the 
 same for the majority of the code I'm only showing D and talk 
 of C++'s choice. While the rules governing D's behavior are 
 fairly simple I feel that I've expanded on the content enough 
 to provide useful information beyond fixing C++'s problems.

 1. http://he-the-great.livejournal.com/52333.html

What do you mean "D does not provide a decltype"?

typeof(cx) my_cx2 = cx;

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Saturday, 31 May 2014 at 07:32:22 UTC, Kagamin wrote:
 What do you mean "D does not provide a decltype"?

 typeof(cx) my_cx2 = cx;

I'll blame this on my poor knowledge of C++, at this time typeof 
in C++ does not appear to compile, in the way I'm trying to use 
it. I thought using typeof in C++ would result in the same answer 
as the deduction auto provides.

 From that point of view, there is no need for decltype, because 
typeof already gives you the actual type in D (which will be the 
same as the type at declaration).

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Saturday, 31 May 2014 at 17:49:18 UTC, Jesse Phillips wrote:
 On Saturday, 31 May 2014 at 07:32:22 UTC, Kagamin wrote:
 What do you mean "D does not provide a decltype"?

 typeof(cx) my_cx2 = cx;

 I'll blame this on my poor knowledge of C++, at this time 
 typeof in C++ does not appear to compile, in the way I'm trying 
 to use it. I thought using typeof in C++ would result in the 
 same answer as the deduction auto provides.

 From that point of view, there is no need for decltype, because 
 typeof already gives you the actual type in D (which will be 
 the same as the type at declaration).

I think you've misunderstood him. You say in the article "D does 
not provide decltype", he is saying that this is misleading: D 
does but it's just called typeof instead.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Saturday, 31 May 2014 at 18:12:12 UTC, John Colvin wrote:
 I think you've misunderstood him. You say in the article "D 
 does not provide decltype", he is saying that this is 
 misleading: D does but it's just called typeof instead.

No, I understood and had adjusted the article with "D does not 
provide a decltype as typeof already does the same thing;" I 
think this is ok since I'd already made use of typeof to assert 
expected types without explanation.

Anyway, I've got Part 6 out there and it looks like I'll have 2 
more short parts which follow.

Walter Bright <newshound2 digitalmars.com> writes:

On 5/27/2014 10:40 PM, Jesse Phillips wrote:
 When he explained why C++ inferred a const int type as int, he tripped me up
 because D does drop const for value types. But D does the simple to explain
 thing, may not be the expected thing (seen questions about it in D.learn), but
 it is simple to explain.

We have at times opted for an "easy to explain" rule rather than a semantically 
perfect one. For example, I've rejected several proposals to make function 
overloading more fine-grained on such grounds.

I've rarely met anyone who could explain how C++'s function overloading rules 
actually work, they just try arbitrary things until it selects the function
they 
want it to.

"Kagamin" <spam here.lot> writes:

On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
 When he explained why C++ inferred a const int type as int, he 
 tripped me up because D does drop const for value types.

Hmm, this bit me (doesn't compile):
void f(in char[] s)
{
   auto s1=s;
   s1=s;
}

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Thursday, 29 May 2014 at 10:41:59 UTC, Kagamin wrote:
 On Wednesday, 28 May 2014 at 05:40:26 UTC, Jesse Phillips wrote:
 When he explained why C++ inferred a const int type as int, he 
 tripped me up because D does drop const for value types.

 Hmm, this bit me (doesn't compile):
 void f(in char[] s)
 {
   auto s1=s;
   s1=s;
 }

I suppose at this point you know:

     void f(const(char)[] s);

I understanding that expected may not be the same as simple. But 
you did ask for s1 to be const then tried to modify it.

anonymous_me <anon hereandthere.com> writes:

On Wed, 28 May 2014 04:48:09 +0000, Jesse Phillips wrote:

 On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu 
 wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 https://news.ycombinator.com/newest (search that page, if not 
 found click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777


 Andrei

 
 I did a translation of most of the code in the slides.
 
 http://dpaste.dzfl.pl/72b5cfcb72e4
 
 I'm planning to transform it into blog post (or series). Right 
 now it just has some scratch notes. Feel free to let me know 
 everything I got wrong.

The first line:

  int x2; // (at global scope)

The x2 resides in Thread Local Storage (TLS). A __gshared would put it in
global scope.
Still initialized to int.init which is zero.

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 28 May 2014 at 14:39:53 UTC, anonymous_me wrote:
 The first line:

   int x2; // (at global scope)

 The x2 resides in Thread Local Storage (TLS). A __gshared would 
 put it in global scope.
 Still initialized to int.init which is zero.

D doesn't have global scope. C++ does not do TLS but that isn't 
relevant to the no cost position that C++ is taking.

Jacob Carlborg <doob me.com> writes:

On 2014-05-28 16:56, Jesse Phillips wrote:

 D doesn't have global scope. C++ does not do TLS but that isn't relevant
 to the no cost position that C++ is taking.

Since C++11 there's "thread_local".

-- 
/Jacob Carlborg

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote:
 I did a translation of most of the code in the slides.

 http://dpaste.dzfl.pl/72b5cfcb72e4

 I'm planning to transform it into blog post (or series). Right 
 now it just has some scratch notes. Feel free to let me know 
 everything I got wrong.

Hoping someone can confirm or deny this thought.

     int x2prime = void; // (at global scope)

Since x2prime is module variable, I would expect that the 
compiler will always initialize this to 0 since there isn't 
really a performance hit. Or is using void guarantee it won't get 
initialized (so much value in that guarantee)?

"Kagamin" <spam here.lot> writes:

On Thursday, 29 May 2014 at 02:38:56 UTC, Jesse Phillips wrote:
 Hoping someone can confirm or deny this thought.

     int x2prime = void; // (at global scope)

 Since x2prime is module variable, I would expect that the 
 compiler will always initialize this to 0 since there isn't 
 really a performance hit. Or is using void guarantee it won't 
 get initialized (so much value in that guarantee)?

Depends on the implementation of tls, usually the .tls section is 
initialized data.

Leandro Lucarella <luca llucax.com.ar> writes:

Jesse Phillips, el 29 de May a las 02:38 me escribiste:
 On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote:
I did a translation of most of the code in the slides.

http://dpaste.dzfl.pl/72b5cfcb72e4

I'm planning to transform it into blog post (or series). Right now
it just has some scratch notes. Feel free to let me know
everything I got wrong.

 
 Hoping someone can confirm or deny this thought.
 
     int x2prime = void; // (at global scope)
 
 Since x2prime is module variable, I would expect that the compiler
 will always initialize this to 0 since there isn't really a
 performance hit. Or is using void guarantee it won't get initialized
 (so much value in that guarantee)?

global/static variables are placed in a special section in the
executable. You need to put some value on it, so it is sensible to put
the same value you use for initialization, but a compiler implementation
could use a different value. I think void means "you don't know what the
value is", not "is a random value" or "a value different from the
default" (which is impossible for stack values, at least if the idea
behind void is to avoid the extra runtime cost ;).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
You should've seen her face. It was the exact same look my father gave
me when I told him I wanted to be a ventriloquist.
	-- George Constanza

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote:
 I think void means "you don't know what the
 value is", not "is a random value" or "a value different from 
 the
 default" (which is impossible for stack values, at least if the 
 idea
 behind void is to avoid the extra runtime cost ;).

The language docs state, "If the Initializer is void, however, 
the variable is not initialized." Which I suspect is false in the 
case of module scope and as Steven pointed out, other times doing 
special "don't init" is costly.

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 7:28 AM, Jesse Phillips wrote:
 The language docs state, "If the Initializer is void, however, the variable is
 not initialized." Which I suspect is false in the case of module scope and as
 Steven pointed out, other times doing special "don't init" is costly.

The language does not guarantee it is initialized. That doesn't mean it has no 
value, however. It means its initial value must not be relied upon.

While the current implementations puts them in BSS which is set to 0 before 
program start, it doesn't have to be done that way. Embedded systems that don't 
have loaders, for example, may map it onto RAM and that RAM may have whatever 
garbage in them that appeared when power was applied.

Leandro Lucarella <luca llucax.com.ar> writes:

Jesse Phillips, el 29 de May a las 14:28 me escribiste:
 On Thursday, 29 May 2014 at 11:08:03 UTC, Leandro Lucarella wrote:
I think void means "you don't know what the
value is", not "is a random value" or "a value different from the
default" (which is impossible for stack values, at least if the
idea
behind void is to avoid the extra runtime cost ;).

 
 The language docs state, "If the Initializer is void, however, the
 variable is not initialized." Which I suspect is false in the case
 of module scope and as Steven pointed out, other times doing special
 "don't init" is costly.

The thing is, you cannot not initialize a variable while writing the
binary file to disk, you have to write something. Is not like with the
stack that you can increase a pointer and leave the memory as is.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
We are born naked, wet and hungry
Then things get worse

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Wed, 28 May 2014 22:38:55 -0400, Jesse Phillips  
<Jesse.K.Phillips+D gmail.com> wrote:

 On Wednesday, 28 May 2014 at 04:48:11 UTC, Jesse Phillips wrote:
 I did a translation of most of the code in the slides.

 http://dpaste.dzfl.pl/72b5cfcb72e4

 I'm planning to transform it into blog post (or series). Right now it  
 just has some scratch notes. Feel free to let me know everything I got  
 wrong.

 Hoping someone can confirm or deny this thought.

      int x2prime = void; // (at global scope)

 Since x2prime is module variable, I would expect that the compiler will  
 always initialize this to 0 since there isn't really a performance hit.  
 Or is using void guarantee it won't get initialized (so much value in  
 that guarantee)?

IIRC, the entire section of global TLS data is initialized, and is all  
contiguous memory, so it would be anti-performant to initialize all but 4  
bytes.

Note:

struct X
{
   int a;
   int b = void; // also initialized to 0.
}

This is because X must blit an init for a, and it would be silly to go  
through the trouble of blitting X.init to a, but not b. Especially, for  
instance, if you had an array of X (you'd have to blit every other int!)

-Steve

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Thursday, 29 May 2014 at 13:11:52 UTC, Steven Schveighoffer 
wrote:
 IIRC, the entire section of global TLS data is initialized, and 
 is all contiguous memory, so it would be anti-performant to 
 initialize all but 4 bytes.

     int x2;
     float f2;

These are both TLS and they init to different values, I suppose:

     float f2prime = void;

would mean f2prime is 0 and not float.init. Otherwise what you 
state is kind of what I was expecting.

 Note:

 struct X
 {
   int a;
   int b = void; // also initialized to 0.
 }

 This is because X must blit an init for a, and it would be 
 silly to go through the trouble of blitting X.init to a, but 
 not b. Especially, for instance, if you had an array of X 
 (you'd have to blit every other int!)

 -Steve

Thanks for the bonus example.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 10:20:39 -0400, Jesse Phillips  
<Jesse.K.Phillips+D gmail.com> wrote:

 On Thursday, 29 May 2014 at 13:11:52 UTC, Steven Schveighoffer wrote:
 IIRC, the entire section of global TLS data is initialized, and is all  
 contiguous memory, so it would be anti-performant to initialize all but  
 4 bytes.

      int x2;
      float f2;

 These are both TLS and they init to different values, I suppose:

      float f2prime = void;

 would mean f2prime is 0 and not float.init. Otherwise what you state is  
 kind of what I was expecting.

This is not what I would have expected. But one can test easily enough :)

http://dpaste.dzfl.pl/6619cf538f8e

I find this interesting. I would have expected the TLS initialization to  
be one giant memcpy. If it is, I find it puzzling that these would be  
different.

The only logical explanation is that TLS is initialized first with all  
zeros, and then specific inits are overlaid on types that have inits.  
Otherwise, what difference does it make if you are blitting 0's or nans?

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
 struct X
 {
    int a;
    int b = void; // also initialized to 0.
 }

 This is because X must blit an init for a, and it would be silly to go through
 the trouble of blitting X.init to a, but not b. Especially, for instance, if
you
 had an array of X (you'd have to blit every other int!)

But it would not be silly for:

   struct X {
      int a;
      int[100] b = void;
   }

to only initialize X.a. The compiler is allowed to optimize that. And, in fact, 
I wished for just this in Warp.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 13:12:24 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 5/29/2014 6:11 AM, Steven Schveighoffer wrote:
 struct X
 {
    int a;
    int b = void; // also initialized to 0.
 }

 This is because X must blit an init for a, and it would be silly to go  
 through
 the trouble of blitting X.init to a, but not b. Especially, for  
 instance, if you
 had an array of X (you'd have to blit every other int!)

 But it would not be silly for:

    struct X {
       int a;
       int[100] b = void;
    }

 to only initialize X.a. The compiler is allowed to optimize that. And,  
 in fact, I wished for just this in Warp.

I don't disagree. I think the spec should not specify what happens, to  
leave it open for future optimizations.

Has anyone ever considered making the compiler build an 'optimized'  
init-blitting function instead of just defaulting to memcpy? In other  
words, the compiler knows at compile time the layout and initialization  
values of a struct. What about using the compiler and optimizer to create  
the most optimized, no-runtime-variables function to blit memory? We  
wouldn't even need compiler help, if we did it with RTInfo.

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 10:54 AM, Steven Schveighoffer wrote:
 Has anyone ever considered making the compiler build an 'optimized'
 init-blitting function instead of just defaulting to memcpy? In other words,
the
 compiler knows at compile time the layout and initialization values of a
struct.
 What about using the compiler and optimizer to create the most optimized,
 no-runtime-variables function to blit memory? We wouldn't even need compiler
 help, if we did it with RTInfo.

I have, but obviously I haven't done anything about it.

"Rene Zwanenburg" <renezwanenburg gmail.com> writes:

On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 https://news.ycombinator.com/newest (search that page, if not 
 found click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777


 Andrei

I just noticed someone posted a link to the talk at gamedev[0]. I 
don't know who the poster is but the gamedev.net community is 
pretty large; this should result in quite some extra views :)

[0] 
http://www.gamedev.net/topic/657103-scott-meyers-the-last-thing-d-needs/

"Andrzej Dwojczynski" <adwojnowski poczta.onet.pl> writes:

On Wednesday, 28 May 2014 at 08:58:34 UTC, Rene Zwanenburg wrote:
 I just noticed someone posted a link to the talk at gamedev[0]. 
 I don't know who the poster is but the gamedev.net community is 
 pretty large; this should result in quite some extra views :)

Out of curiosity - did anyone try to post it to slashdot?
If not as a news article then maybe in the comments?

Andrzej

 [0] 
 http://www.gamedev.net/topic/657103-scott-meyers-the-last-thing-d-needs/

Jonathan M Davis via Digitalmars-d-announce writes:

<html><head></head><body><div style="font-family: Verdana;font-size:
12.0px;"><div>On Tue, 27 May 2014 06:42:41 -1000<br/>
Andrei Alexandrescu via Digitalmars-d-announce<br/>
&lt;digitalmars-d-announce puremagic.com&gt; wrote:<br/>
<br/>
&gt; <a href="http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynot
_the_last_thing_d/" target="_blank">http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/</a><br/>
&gt;<br/>
&gt; <a href="https://news.ycombinator.com/newest"
target="_blank">https://news.ycombinator.com/newest</a> (search that page, if
not found<br/>
&gt; click &quot;More&quot; and search again)<br/>
&gt;<br/>
&gt; <a href="https://www.facebook.com/dlang.org/posts/855022447844771"
target="_blank">https://www.facebook.com/dlang.org/posts/855022447844771</a><br/>
&gt;<br/>
&gt; <a href="https://twitter.com/D_Programming/status/471330026168651777"
target="_blank">https://twitter.com/D_Programming/status/471330026168651777</a><br/>
<br/>

inconsistencies that Scott describes for C++, but we do definitely have
some<br/>
of our own. The ones that come to mind at the moment are:<br/>
<br/>
1. The order of the dimensions of multi-dimensional static arrays is
backwards<br/>
in comparison to what most everyone expects.<br/>
<br/>
&nbsp; &nbsp; int[4][5][6] foo;<br/>
<br/>
is the same as<br/>
<br/>
&nbsp; &nbsp; int foo[6][5][4];<br/>
<br/>
and has the same dimensions as<br/>
<br/>
&nbsp; &nbsp; auto bar = new int[][][](6, 5, 4);<br/>
<br/>
The reasons for it stem from the fact that the compiler reads types outward<br/>
from the variable name (which is very important to understand in C because
of<br/>
its function pointer syntax but not so important in D). However, once we
did<br/>
<br/>
&nbsp; &nbsp; const(int)* foo;<br/>
<br/>

<br/>
&nbsp; &nbsp; (int)const* foo;<br/>
<br/>
I think that we threw that particular bit of consistency with C/C++ out the<br/>
window, and we really should have just made static array dimensions be read<br/>
from left-to-right.<br/>
<br/>

doing<br/>
so would cause silent breakage (or at minimum, would be silent until<br/>
RangeErrors were thrown at runtime).<br/>
<br/>
<br/>

<br/>
&nbsp; &nbsp; auto foo = new int[5];<br/>
<br/>
is the same as<br/>
<br/>
&nbsp; &nbsp; auto foo = new int[](5);<br/>
<br/>

because<br/>
<br/>
&nbsp; &nbsp; auto foo = new int[4][5][6];<br/>
<br/>
does _not_ declare a multi-dimensional dynimac array but rather a dynamic<br/>
array of length 6 which contains a multi-dimensonal static array of
dimensions<br/>
4 and 5. Instead, what you need to do is<br/>
<br/>
&nbsp; &nbsp; auto foo = new int[][][](4, 5, 6);<br/>
<br/>
IMHO, we should have made it illegal to have dynamic array dimensions
inside<br/>

change<br/>

of<br/>
existing code would be broken - especially because so many people put the<br/>
array dimensions between the brackets for single-dimension dynamic arrays.<br/>
<br/>
<br/>
3. const, immutable, and inout on the left-hand side of a function
declaration<br/>
are unfortunately legal. This inevitably trips people up, because they
think<br/>
that the attribute applies to the return type, when it applies to the
function<br/>
itself. This is to make the function attributes consistent, because all of<br/>

bad<br/>
practice to ever put any attribute on the left-hand side which could apply
to<br/>
the return type, because it looks like a bug. If we just made it illegal
for<br/>
those attributes to go on the left, the problem would be solved, and the<br/>
result would be far less confusing and bug-prone. I think that we can make<br/>

them<br/>
no the left-hand side), but AFAIK, Walter is against the idea.<br/>
<br/>
<br/>
4. There are some cases (such as with static constructors and unittest
blocks)<br/>

remember<br/>

even<br/>
seasoned D programmers from time to time.<br/>
<br/>
<br/>
5. The fact that pure is called pure is very problematic at this point as
far<br/>
as explaining things to folks goes. We should probably consider renaming it
to<br/>

well<br/>
given the amount of breakage involved. It _does_ require a lot of
explaining<br/>
though.<br/>
<br/>
<br/>
6. The situation with ranges and string is kind of ugly, with them being<br/>

to<br/>
this is, since treating them as ranges of code units promotes efficiency
but<br/>
makes code more error-prone, whereas treating them as ranges of graphemes<br/>
would just cost too much. Ranges of code points is _mostly_ correct but
still<br/>
incorrect and _more_ efficient than graphemes but still quite a bit less<br/>

worst<br/>
of both worlds. The current situation causes inconsistencies with
everything<br/>
else (forcing us to use isNarrowString all over the place) and definitely<br/>
requires frequent explaining, but it does prevent some classes of problems.<br/>

this<br/>

treating<br/>
them as ranges of code units and then have wrappers for ranges of code
points<br/>
or graphemes. It seems like the current situation promotes either using<br/>
ubyte[] (if you care about efficiency) or the new grapheme facilities in<br/>
std.uni if you care about correctness, whereas just using strings as ranges
of<br/>

of<br/>

willing<br/>
have bugs in the areas where operating at the code point level is
incorrect.<br/>
<br/>
<br/>
7. There are several minor inconsistencies with local imports and nested<br/>
functions in comparison to module-level imports or free functions, and I
think<br/>

be.<br/>
<br/>
<br/>

are<br/>
others, and this post is already probbaly too long). So, we definitely have<br/>

off<br/>
than C++ in that regard. Fortunately, while Phobos still has some naming<br/>
issues, a lot of the naming inconsistencies were sorted out a couple of
years<br/>
ago, and we have solved a number of other inconsistencies in the language
and<br/>

number<br/>
of inconsistencies that we have rather than increasing them. But we should<br/>
look at reducing them further if we can and should _definitely_ keep an eye<br/>
out for areas where more inconsistencies could creep in.<br/>
<br/>
- Jonathan M Davis</div></div></body></html>

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/28/2014 03:10 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

 On Tue, 27 May 2014 06:42:41 -1000
 Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

   >
 

http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
   >
   > https://news.ycombinator.com/newest (search that page, if not found
   > click "More" and search again)
   >
   > https://www.facebook.com/dlang.org/posts/855022447844771
   >
   > https://twitter.com/D_Programming/status/471330026168651777

 Fortunately, for the most part, I think that we've avoided the types of
 inconsistencies that Scott describes for C++, but we do definitely 

have some
 of our own. The ones that come to mind at the moment are:

 1. The order of the dimensions of multi-dimensional static arrays is 

backwards
 in comparison to what most everyone expects.

However, those expectations are based on the inside-out syntax of C. 
Naturally, wanting to be consistent, especially compared to C, D should 
deviate from that syntax.

       int[4][5][6] foo;

That is sane: It is alwasy "first the type then the size":

int[1]    good
Animal[2] good

Following from that rule (i.e. first type, then size), how would I have 
an array of 3 elements where each element is an array of 4 elements. 
Let's see... Each element is int[4]. There:

int[4]

Then, I want an array of 3 of those. There:

int[4][3] good

This is one of the commonish arguments in the D forums that I have the 
strongest opinion because there is no problem with D's syntax at all. It 
is consistent.

It is consistent even when indexing. The index is for the array:

int[1] a;
a[0];     // the first element of a; it is an int

int[2][3] b;
b[0];     // the first element of b; it is an int[2]

I don't see any problem at all. :)

Remembering that there is no such thing as a multi-dimensional array in 
D (nor C), it just follows naturally:

b[0][1];  // the second int of the first int[2]

 is the same as

       int foo[6][5][4];

That's beyond ridiculous. I am glad that D avoided that problem for both 
function pointers and arrays.

 and has the same dimensions as

       auto bar = new int[][][](6, 5, 4);

That makes perfect sense to me, because this is a function API, not D 
syntax. There is no ambiguity in saying "you go deeper into the element 
sizes as you provide the arguments."

Ali

"Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:

On Wednesday, 28 May 2014 at 22:42:03 UTC, Ali Çehreli wrote:
 However, those expectations are based on the inside-out syntax 
 of C. Naturally, wanting to be consistent, especially compared 
 to C, D should deviate from that syntax.

I don't get to read the original email, but I agree with the 
examples you pull out. D's array declaration syntax is so nice. 
The support for C style syntax is unfortunate though.

Walter Bright <newshound2 digitalmars.com> writes:

Some of the inconsistencies you mentioned and Brian mentioned in his talk are 
actually the result of consistencies.

I know this is a bit of a difficult thing to wrap one's head around, but having 
something be mathematically consistent and humanly consistent are often at 
severe odds.

"Brian Rogoff" <brogoff gmail.com> writes:

On Wednesday, 28 May 2014 at 23:07:07 UTC, Walter Bright wrote:
 Some of the inconsistencies you mentioned and Brian mentioned 
 in his talk are actually the result of consistencies.

 I know this is a bit of a difficult thing to wrap one's head 
 around, but having something be mathematically consistent and 
 humanly consistent are often at severe odds.

Could you elaborate? Using some of the examples Brian gave, which 
ones do you think are are mathematically consistent/human 
inconsistent and which the inverse?

Walter Bright <newshound2 digitalmars.com> writes:

On 5/28/2014 5:35 PM, Brian Rogoff wrote:
 Could you elaborate? Using some of the examples Brian gave, which ones do you
 think are are mathematically consistent/human inconsistent and which the
inverse?

Off the top of my head:

     static if (condition)
     else :

     ... declarations ...

All attributes apply to either:

1. the next statement or declaration
2. { ... }
3. : ...

That case is (3), as static if is set up as an attribute.

"Brian Schott" <briancschott gmail.com> writes:

On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
 Off the top of my head:

     static if (condition)
     else :

     ... declarations ...

 All attributes apply to either:

 1. the next statement or declaration
 2. { ... }
 3. : ...

 That case is (3), as static if is set up as an attribute.

Static if is not an attribute.

ConditionalStatement:
     Condition NoScopeNonEmptyStatement
     Condition NoScopeNonEmptyStatement else 
NoScopeNonEmptyStatement

Condition:
     VersionCondition
     DebugCondition
     StaticIfCondition

Attribute:
     LinkageAttribute
     AlignAttribute
     DeprecatedAttribute
     ProtectionAttribute
     Pragma
     static
     extern
     abstract
     final
     override
     synchronized
     auto
     scope
     const
     immutable
     inout
     shared
     __gshared
     Property
     nothrow
     pure
     ref

Walter Bright <newshound2 digitalmars.com> writes:

On 5/28/2014 6:06 PM, Brian Schott wrote:
 On Thursday, 29 May 2014 at 00:58:35 UTC, Walter Bright wrote:
 Off the top of my head:

     static if (condition)
     else :

     ... declarations ...

 All attributes apply to either:

 1. the next statement or declaration
 2. { ... }
 3. : ...

 That case is (3), as static if is set up as an attribute.

 Static if is not an attribute.

They are handled that way by the parser.

https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L379

Looks like there's an omission in the grammar. Thanks for pointing it out.

https://issues.dlang.org/show_bug.cgi?id=12818



 ConditionalStatement:
      Condition NoScopeNonEmptyStatement
      Condition NoScopeNonEmptyStatement else NoScopeNonEmptyStatement

 Condition:
      VersionCondition
      DebugCondition
      StaticIfCondition

 Attribute:
      LinkageAttribute
      AlignAttribute
      DeprecatedAttribute
      ProtectionAttribute
      Pragma
      static
      extern
      abstract
      final
      override
      synchronized
      auto
      scope
      const
      immutable
      inout
      shared
      __gshared
      Property
      nothrow
      pure
      ref

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

29-May-2014 04:58, Walter Bright пишет:
 On 5/28/2014 5:35 PM, Brian Rogoff wrote:
 Could you elaborate? Using some of the examples Brian gave, which ones
 do you
 think are are mathematically consistent/human inconsistent and which
 the inverse?

 Off the top of my head:

      static if (condition)
      else :

      ... declarations ...

 All attributes apply to either:

 1. the next statement or declaration
 2. { ... }
 3. : ...

 That case is (3), as static if is set up as an attribute.

Static if is certainly NOT an attribute, it doesn't make any sense.
And no, it doesn't matter how the current frontend implements it, 
because you can argue next to any decisions this way.

-- 
Dmitry Olshansky

"Brian Schott" <briancschott gmail.com> writes:

On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky wrote:
 And no, it doesn't matter how the current frontend implements 
 it, because you can argue next to any decisions this way.

When issues like this come up the spec is almost always changed 
to match the DMD front end instead of the other way around.

Why are we afraid of breaking code that relied on behavior that 
was not in the language specification? That makes it almost 
impossible to fix accepts-invalid bugs.

"Brian Rogoff" <brogoff gmail.com> writes:

On Thursday, 29 May 2014 at 18:52:53 UTC, Brian Schott wrote:
 On Thursday, 29 May 2014 at 18:12:10 UTC, Dmitry Olshansky 
 wrote:
 And no, it doesn't matter how the current frontend implements 
 it, because you can argue next to any decisions this way.

 When issues like this come up the spec is almost always changed 
 to match the DMD front end instead of the other way around.

I believe that the result of this policy will be that the D 
community will need to have Scott Meyers or someone like him to 
explain some of these issues. :-)

It may not be as bad as C++, but is that how we want to measure a 
language design? "Sure, it looks bad, but it could have been so 
much worse!"

 Why are we afraid of breaking code that relied on behavior that 
 was not in the language specification?

My guess is that the fear of 'breaking' some users' code is too 
great right now. That was one of the things I took from Meyers' 
talk; the D designers still have an opportunity to be bold in 
introducing changes that make the entire design better (more 
easily explainable) while in C++ that opportunity has probably 
passed.

 That makes it almost impossible to fix accepts-invalid bugs.

It's a problem that needs to be addressed. Thanks for your 
efforts and for continually reminding people. I really liked your 
lightning talk; it could have followed Meyers' and maybe the 
right people would have been shamed into action.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky  =

<dmitry.olsh gmail.com> wrote:

 29-May-2014 04:58, Walter Bright =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On 5/28/2014 5:35 PM, Brian Rogoff wrote:
 Could you elaborate? Using some of the examples Brian gave, which on=



es
 do you
 think are are mathematically consistent/human inconsistent and which=



 the inverse?

 Off the top of my head:

      static if (condition)
      else :

      ... declarations ...

 All attributes apply to either:

 1. the next statement or declaration
 2. { ... }
 3. : ...

 That case is (3), as static if is set up as an attribute.

 Static if is certainly NOT an attribute, it doesn't make any sense.

Well... it sorta does. static if does not introduce a new scope, even wi=
th  =

{}, and this only happens with attributes.

-Steve

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

29-May-2014 23:06, Steven Schveighoffer пишет:
 On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
 <dmitry.olsh gmail.com> wrote:

 29-May-2014 04:58, Walter Bright пишет:
 On 5/28/2014 5:35 PM, Brian Rogoff wrote:
 Could you elaborate? Using some of the examples Brian gave, which ones
 do you
 think are are mathematically consistent/human inconsistent and which
 the inverse?

 Off the top of my head:

      static if (condition)
      else :

      ... declarations ...

 All attributes apply to either:

 1. the next statement or declaration
 2. { ... }
 3. : ...

 That case is (3), as static if is set up as an attribute.

 Static if is certainly NOT an attribute, it doesn't make any sense.

 Well... it sorta does. static if does not introduce a new scope, even
 with {}, and this only happens with attributes.

Let it be just a declaration, as simple as that. Attributes affect other 
declarations in the scope, static if doesn't.

 -Steve


-- 
Dmitry Olshansky

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 15:24:06 -0400, Dmitry Olshansky  
<dmitry.olsh gmail.com> wrote:

 Let it be just a declaration, as simple as that. Attributes affect other  
 declarations in the scope, static if doesn't.

Sure it does:

private:
    int a;
    int b;

equivalent to

private int a;
private int b;

static if(x):
    int a;
    int b;

equivalent to

static if(x) int a;
static if(x) int b;

;)

Yes, I agree static if does not fit the understood meaning of an  
attribute. And it can apply to statements too, whereas attributes can only  
apply to declarations (right?).

In reality, static if is in a league with version and debug, and they  
share similarities to both statements and attributes.

-Steve

"deadalnix" <deadalnix gmail.com> writes:

On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
wrote:
 Static if is certainly NOT an attribute, it doesn't make any 
 sense.

 Well... it sorta does. static if does not introduce a new 
 scope, even with {}, and this only happens with attributes.

 -Steve

in which case

static if(cond) {
immutable:
}

int x;

should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 21:15:21 -0400, deadalnix <deadalnix gmail.com> wrote:

 On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
 wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

 Well... it sorta does. static if does not introduce a new scope, even  
 with {}, and this only happens with attributes.

 -Steve

 in which case

 static if(cond) {
 immutable:
 }

 int x;

 should not create x as immutable if cond is true. The current
 behavior is not consistent with attribute either.

Ugh, that is really bad. It shouldn't do that. Is that intentional?

-Steve

Timon Gehr <timon.gehr gmx.ch> writes:

On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:

 in which case

 static if(cond) {
 immutable:
 }

 int x;

 should not create x as immutable if cond is true. The current
 behavior is not consistent with attribute either.

 Ugh, that is really bad. It shouldn't do that. Is that intentional?

enum cond=true;

static if(cond){
immutable:
}

int x;
static assert(is(typeof(x)==int));

What is the problem?

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 31 May 2014 18:56:17 -0400, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:

 in which case

 static if(cond) {
 immutable:
 }

 int x;

 should not create x as immutable if cond is true. The current
 behavior is not consistent with attribute either.

 Ugh, that is really bad. It shouldn't do that. Is that intentional?

 enum cond=true;

 static if(cond){
 immutable:
 }

 int x;
 static assert(is(typeof(x)==int));

 What is the problem?

OK, so the original premise is not true? I was assuming deadalnix was  
saying x would be immutable.

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
 On Thu, 29 May 2014 21:15:21 -0400, deadalnix <deadalnix gmail.com> wrote:

 On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
 wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

 Well... it sorta does. static if does not introduce a new scope, even with
 {}, and this only happens with attributes.

 -Steve

 in which case

 static if(cond) {
 immutable:
 }

 int x;

 should not create x as immutable if cond is true. The current
 behavior is not consistent with attribute either.

 Ugh, that is really bad. It shouldn't do that. Is that intentional?

Yes. Semantic scope and lexical scope are different things. The ':' thing 
applies to the remaining statements in the lexical scope. 'static if' does not 
create a new semantic scope, even though the { } suggests it does.

There have been several suggestions to make 'static if' apply independently of 
the rest of the grammar, i.e. allow things like:

     int static if (cond) * else [ ] foo; // conditionally make foo a pointer
or 
an array

I think we can agree that looks awful, but it is the same thing as suggesting 
that the 'immutable:' above extend outside of its lexical scope.


You might ask "why is semantic scope different from lexical scope" and the 
reason is simply that 'static if' would not be very useful if that were the
case.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 31 May 2014 19:27:08 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
 On Thu, 29 May 2014 21:15:21 -0400, deadalnix <deadalnix gmail.com>  
 wrote:

 On Thursday, 29 May 2014 at 19:06:15 UTC, Steven Schveighoffer
 wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

 Well... it sorta does. static if does not introduce a new scope, even  
 with
 {}, and this only happens with attributes.

 -Steve

 in which case

 static if(cond) {
 immutable:
 }

 int x;

 should not create x as immutable if cond is true. The current
 behavior is not consistent with attribute either.

 Ugh, that is really bad. It shouldn't do that. Is that intentional?

 Yes. Semantic scope and lexical scope are different things. The ':'  
 thing applies to the remaining statements in the lexical scope. 'static  
 if' does not create a new semantic scope, even though the { } suggests  
 it does.

deadalnix's suggestion, at least to me, was that currently the compiler  
would attribute immutable to int x. Testing, I see it does not. Maybe I  
misinterpreted the implication. The statement "current behavior is not  
consistent with attribute" seems wrong then.

 There have been several suggestions to make 'static if' apply  
 independently of the rest of the grammar, i.e. allow things like:

      int static if (cond) * else [ ] foo; // conditionally make foo a  
 pointer or an array

 I think we can agree that looks awful, but it is the same thing as  
 suggesting that the 'immutable:' above extend outside of its lexical  
 scope.

I agree, I think we are arguing the same thing.

static if seems like an attribute in how it scopes things.

-Steve

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

Yes, it does make sense. It was not an accident that the frontend treats it as 
it does, the code to do it was deliberately put there.

The attributes are all designed to affect a block of code - so are 
version/debug/staticif - why should they be different?

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 29 May 2014 15:29:31 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

 Yes, it does make sense. It was not an accident that the frontend treats  
 it as it does, the code to do it was deliberately put there.

 The attributes are all designed to affect a block of code - so are  
 version/debug/staticif - why should they be different?

private int x; // ok
static if(1) int x; // ok

private x = 5; // error
static if(1) x = 5; // ok

Static if/version/debug can affect both statements and declarations.  
attributes only apply to declarations. That is the major difference I see  
between them.

Not arguing that it's bad for the syntax to exist, I think it kind of  
makes sense given that static if does not create a new scope. But they  
don't behave like normal attributes.

-Steve

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

29-May-2014 23:29, Walter Bright пишет:
 On 5/29/2014 11:11 AM, Dmitry Olshansky wrote:
 Static if is certainly NOT an attribute, it doesn't make any sense.

 Yes, it does make sense. It was not an accident that the frontend treats
 it as it does, the code to do it was deliberately put there.

With the reason being? I could deliberately put any code anywhere.

 The attributes are all designed to affect a block of code - so are
 version/debug/staticif - why should they be different?

Because they are different constructs?
static if models if-else, so does the version statement BTW (else 
version). debug doesn't model if-else. I could see *some* common ground 
between them.

safe/pure/nogc etc. are different in that they all affect symbols and 
have no conditional clause, *some* of them even have counterparts 
(consistency? - I do not see any).

This for instance doesn't work:

static if(1):
     int blah;
else
{}

while this does:

static if(1)
     int blah;
else:


Does it make any sense? To me - no, not at all.
Not every decision must be taken on the grounds of making some code in 
compiler more straightforward.
After all C's #include was so simple to implement and we know where this 
way leads to.

-- 
Dmitry Olshansky

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 3:19 PM, Dmitry Olshansky wrote:
 With the reason being?

The same reason you might want to put:

    nogc:
   ...

at the beginning of a source module instead of:

    nogc: {
     ...
   }

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

29-May-2014 02:10, Jonathan M Davis via Digitalmars-d-announce пишет:
 On Tue, 27 May 2014 06:42:41 -1000
 Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

  >
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
  >
  > https://news.ycombinator.com/newest (search that page, if not found
  > click "More" and search again)
  >
  > https://www.facebook.com/dlang.org/posts/855022447844771
  >
  > https://twitter.com/D_Programming/status/471330026168651777

 Fortunately, for the most part, I think that we've avoided the types of
 inconsistencies that Scott describes for C++, but we do definitely have some
 of our own. The ones that come to mind at the moment are:

Not talking about other moments, but Unicode kind of caught my eye..
 6. The situation with ranges and string is kind of ugly, with them being
 treated as ranges of code points. I don't know what the correct solution to
 this is, since treating them as ranges of code units promotes efficiency but
 makes code more error-prone, whereas treating them as ranges of graphemes
 would just cost too much.

This is gross oversimplification of the matter. There is no more 
correct, less correct. Each algorithm requires its own level of 
consideration, if there is a simple truism about Unicode it is:

Never operate on a single character, rather operate on slices of text.

To sum up the situation:

Unicode standard defines *all* of its algorithms in terms of code points 
and some use grapheme clusters. It never says anything about code units 
beyond mapping of code units --> code point. So whether or not you 
should actually decode is up to the implementation.


 Ranges of code points is _mostly_ correct but
 still
 incorrect and _more_ efficient than graphemes but still quite a bit less
 efficient than code units. So, it's kind of like it's got the best and worst
 of both worlds. The current situation causes inconsistencies with everything
 else (forcing us to use isNarrowString all over the place) and definitely
 requires frequent explaining, but it does prevent some classes of problems.
 So, I don't know. I used to be in favor of the current situation, but at
 this
 point, if we could change it, I think that I'd argue in faver of just
 treating
 them as ranges of code units and then have wrappers for ranges of code
 points
 or graphemes.

Agreed. The simple dream of automatically decoding UTF and staying 
"Unicode correct" is a failure.

 It seems like the current situation promotes either using
 ubyte[] (if you care about efficiency) or the new grapheme facilities in
 std.uni if you care about correctness, whereas just using strings as
 ranges of
 dchar is probably a bad idea unless you just don't want to deal with any of
 the Unicode stuff, don't care all that much about efficiency, and are
 willing
 have bugs in the areas where operating at the code point level is incorrect.

The worst thing about current situation is any generic code that works 
on UTF ranges has to jump through unbelievable amount of hoops to undo 
"string has no length" madness.

I think what we should do is define an StringRange or some such, that 
will at least make the current special case of string more generic.

-- 
Dmitry Olshansky

Walter Bright <newshound2 digitalmars.com> writes:

On 5/29/2014 11:25 AM, Dmitry Olshansky wrote:
 Agreed. The simple dream of automatically decoding UTF and staying "Unicode
 correct" is a failure.

Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. It's 
like trying to pretend that floating point does not do rounding.

It's far more practical to embrace what it is and deal with it. Yes, D 
programmers will need to understand what UTF-8 is. I don't see any way around
that.

My proposal for dealing with this, while retaining backwards compatibility, is 
adding the ranges byCodeunit, byChar, byWchar and byDchar which can be applied 
to any string arrays or string ranges.

"Regan Heath" <regan netmail.co.nz> writes:

On Thu, 29 May 2014 20:40:10 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 5/29/2014 11:25 AM, Dmitry Olshansky wrote:
 Agreed. The simple dream of automatically decoding UTF and staying  
 "Unicode
 correct" is a failure.

 Yes. Attempting to hide the fact that strings are UTF-8 is just doomed.  
 It's like trying to pretend that floating point does not do rounding.

 It's far more practical to embrace what it is and deal with it. Yes, D  
 programmers will need to understand what UTF-8 is. I don't see any way  
 around that.

And it's the right choice.  4 of the 7 billion people in the world today  
are in Asia and by 2100 80% of the worlds population will be in Asia and  
Africa.

http://bigthink.com/neurobonkers/it-is-not-about-political-views-or-ideologies-it-is-blunt-facts-which-are-not-known

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Jonathan M Davis via Digitalmars-d-announce writes:

Okay. That seriously got munged. Let's try that again...

On Tue, 27 May 2014 06:42:41 -1000
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 https://news.ycombinator.com/newest (search that page, if not found
 click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777

Fortunately, for the most part, I think that we've avoided the types of
inconsistencies that Scott describes for C++, but we do definitely have some
of our own. The ones that come to mind at the moment are:

1. The order of the dimensions of multi-dimensional static arrays is backwards
in comparison to what most everyone expects.

    int[4][5][6] foo;

is the same as

    int foo[6][5][4];

and has the same dimensions as

    auto bar = new int[][][](6, 5, 4);

The reasons for it stem from the fact that the compiler reads types outward
from the variable name (which is very important to understand in C because of
its function pointer syntax but not so important in D). However, once we did

    const(int)* foo;

and didn't allow

    (int)const* foo;

I think that we threw that particular bit of consistency with C/C++ out the
window, and we really should have just made static array dimensions be read
from left-to-right. Unfortunately, I don't think that we can fix that at this
point, because doing so would cause silent breakage (or at minimum, would be
silent until RangeErrors were thrown at runtime).


2. We're inconsistent with dynamic array dimensions.

    auto foo = new int[5];

is the same as

    auto foo = new int[](5);

but once you get into multi-dimensional arrays, it's just confusing, because

    auto foo = new int[4][5][6];

does _not_ declare a multi-dimensional dynamic array but rather a dynamic
array of length 6 which contains a multi-dimensonal static array of dimensions
4 and 5. Instead, what you need to do is

    auto foo = new int[][][](4, 5, 6);

IMHO, we should have made it illegal to have dynamic array dimensions inside
of the brackets rather than the parens, but I don't know if we can change
that. It wouldn't be silent breakage, but it _would_ make it so that a lot of
existing code would be broken - especially because so many people put the
array dimensions between the brackets for single-dimension dynamic arrays.


3. const, immutable, and inout on the left-hand side of a function declaration
are unfortunately legal. This inevitably trips people up, because they think
that the attribute applies to the return type, when it applies to the function
itself. This is to make the function attributes consistent, because all of the
others can go on either side, but the result is that it's essentially bad
practice to ever put any attribute on the left-hand side which could apply to
the return type, because it looks like a bug. If we just made it illegal for
those attributes to go on the left, the problem would be solved, and the
result would be far less confusing and bug-prone. I think that we can make
that change with minimal breakage (since it's already bad practice to put them
no the left-hand side), but AFAIK, Walter is against the idea.


4. There are some cases (such as with static constructors and unittest blocks)
that the attributes have to go on the left for some reason. I don't remember
the reasons for it, but it's an inconsistency which definitely trips up even
seasoned D programmers from time to time.


5. The fact that pure is called pure is very problematic at this point as far
as explaining things to folks goes. We should probably consider renaming it to
something like  noglobal, but I'm not sure that that would go over very well
given the amount of breakage involved. It _does_ require a lot of explaining
though.


6. The situation with ranges and string is kind of ugly, with them being
treated as ranges of code points. I don't know what the correct solution to
this is, since treating them as ranges of code units promotes efficiency but
makes code more error-prone, whereas treating them as ranges of graphemes
would just cost too much. Ranges of code points is _mostly_ correct but still
incorrect and _more_ efficient than graphemes but still quite a bit less
efficient than code units. So, it's kind of like it's got the best and worst
of both worlds. The current situation causes inconsistencies with everything
else (forcing us to use isNarrowString all over the place) and definitely
requires frequent explaining, but it does prevent some classes of problems.
So, I don't know. I used to be in favor of the current situation, but at this
point, if we could change it, I think that I'd argue in faver of just treating
them as ranges of code units and then have wrappers for ranges of code points
or graphemes. It seems like the current situation promotes either using
ubyte[] (if you care about efficiency) or the new grapheme facilities in
std.uni if you care about correctness, whereas just using strings as ranges of
dchar is probably a bad idea unless you just don't want to deal with any of
the Unicode stuff, don't care all that much about efficiency, and are willing
have bugs in the areas where operating at the code point level is incorrect.


7. There are several minor inconsistencies with local imports and nested
functions in comparison to module-level imports or free functions, and I think
that some of those should be fixed, but I'm not sure that all of them can be.


That's what I can think of at the moment (though I'm sure that there are
others, and this post is already probbaly too long). So, we definitely have
our own consistency issues, but I do think that we're still far better off
than C++ in that regard. Fortunately, while Phobos still has some naming
issues, a lot of the naming inconsistencies were sorted out a couple of years
ago, and we have solved a number of other inconsistencies in the language and
library over time, so if anything, we've probably been _reducing_ the number
of inconsistencies that we have rather than increasing them. But we should
look at reducing them further if we can and should _definitely_ keep an eye
out for areas where more inconsistencies could creep in.

- Jonathan M Davis

"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:

On Thursday, 29 May 2014 at 03:29:31 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:
 1. The order of the dimensions of multi-dimensional static 
 arrays is backwards
 in comparison to what most everyone expects.

     int[4][5][6] foo;

 is the same as

     int foo[6][5][4];

 and has the same dimensions as

     auto bar = new int[][][](6, 5, 4);

 The reasons for it stem from the fact that the compiler reads 
 types outward
 from the variable name (which is very important to understand 
 in C because of
 its function pointer syntax but not so important in D). 
 However, once we did

     const(int)* foo;

 and didn't allow

     (int)const* foo;

 I think that we threw that particular bit of consistency with 
 C/C++ out the
 window, and we really should have just made static array 
 dimensions be read
 from left-to-right. Unfortunately, I don't think that we can 
 fix that at this
 point, because doing so would cause silent breakage (or at 
 minimum, would be
 silent until RangeErrors were thrown at runtime).

I don't see this as an inconsistency. Just read it as follows:

     int[6][5]* foo;

- start with the type int
- make an array from it
- make an array from that
- and finally, turn it into a pointer.

     const(int)* bar;

Just read `const(int)` as one entity here (as its form suggests, 
some kind of "function call"):

- start with a const(int)
- make a pointer from it

 3. const, immutable, and inout on the left-hand side of a 
 function declaration are unfortunately legal.

Agreed. At least it's possible to do it by convention (but see 
4.).

 4. There are some cases (such as with static constructors and 
 unittest blocks)
 that the attributes have to go on the left for some reason. I 
 don't remember
 the reasons for it, but it's an inconsistency which definitely 
 trips up even
 seasoned D programmers from time to time.

I don't know these cases, but the reason might be is that 
function declarations and unittests need to be followed by braces 
(or a semicolon in the case of functions), whereas some other 
keywords also allow non-compound statements. This could therefore 
lead to ambiguities as to whether the type qualifier applies to 
the declaration or the following statement.

 5. The fact that pure is called pure is very problematic at 
 this point as far
 as explaining things to folks goes. We should probably consider 
 renaming it to
 something like  noglobal, but I'm not sure that that would go 
 over very well
 given the amount of breakage involved. It _does_ require a lot 
 of explaining
 though.

Well, it's just a name, and it's for hysterical raisins ;-) I 
don't think it's so bad, because the purity concept already 
differs from language to language.

 6. The situation with ranges and string is kind of ugly, with 
 them being
 treated as ranges of code points. I don't know what the correct 
 solution to
 this is, since treating them as ranges of code units promotes 
 efficiency but
 makes code more error-prone, whereas treating them as ranges of 
 graphemes
 would just cost too much. Ranges of code points is _mostly_ 
 correct but still
 incorrect and _more_ efficient than graphemes but still quite a 
 bit less
 efficient than code units. So, it's kind of like it's got the 
 best and worst
 of both worlds. The current situation causes inconsistencies 
 with everything
 else (forcing us to use isNarrowString all over the place) and 
 definitely
 requires frequent explaining, but it does prevent some classes 
 of problems.
 So, I don't know. I used to be in favor of the current 
 situation, but at this
 point, if we could change it, I think that I'd argue in faver 
 of just treating
 them as ranges of code units and then have wrappers for ranges 
 of code points
 or graphemes. It seems like the current situation promotes 
 either using
 ubyte[] (if you care about efficiency) or the new grapheme 
 facilities in
 std.uni if you care about correctness, whereas just using 
 strings as ranges of
 dchar is probably a bad idea unless you just don't want to deal 
 with any of
 the Unicode stuff, don't care all that much about efficiency, 
 and are willing
 have bugs in the areas where operating at the code point level 
 is incorrect.

My preferred solution would be to disallow iterating over bare 
char/wchar/dchar ranges, but require an explicit .byCodeUnit, 
.byCodePoint or .byGrapheme. Probably not going to happen, 
though...

Jonathan M Davis via Digitalmars-d-announce writes:

On Wed, 28 May 2014 16:07:08 -0700
Walter Bright via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Some of the inconsistencies you mentioned and Brian mentioned in his
 talk are actually the result of consistencies.

 I know this is a bit of a difficult thing to wrap one's head around,
 but having something be mathematically consistent and humanly
 consistent are often at severe odds.

I don't disagree, but I also think that we need to be very careful when
they're at odds, because it tends to result in buggy code when the rules are
inconsistent from the human's perspective. In some cases, it's best to better
educate the programmer, whereas in others, it's better to just make it
consistent for the programmer - especially when you're dealing with a case
where being consistent with one thing means being inconsistent with another.
Overall, I think that we've done a decent job of it, but there are definitely
places (e.g. static array declarations) where I think we botched it.

- Jonathan M Davis

Timon Gehr <timon.gehr gmx.ch> writes:

On 05/29/2014 05:35 AM, Jonathan M Davis via Digitalmars-d-announce wrote:
 On Wed, 28 May 2014 16:07:08 -0700
 Walter Bright via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 Some of the inconsistencies you mentioned and Brian mentioned in his
 talk are actually the result of consistencies.

 I know this is a bit of a difficult thing to wrap one's head around,
 but having something be mathematically consistent and humanly
 consistent are often at severe odds.

 I don't disagree, but I also think that we need to be very careful when
 they're at odds, because it tends to result in buggy code when the rules are
 inconsistent from the human's perspective. In some cases, it's best to better
 educate the programmer, whereas in others, it's better to just make it
 consistent for the programmer - especially when you're dealing with a case
 where being consistent with one thing means being inconsistent with another.
 Overall, I think that we've done a decent job of it, but there are definitely
 places (e.g. static array declarations) where I think we botched it.

 - Jonathan M Davis

I think this is not a point about "consistency", but about intuition.

In any case, simply reversing the order for static array types using an 
ad-hoc rewrite rule would be a huge wart, even more severe than the 
other points you raised, and we definitely wouldn't be trading one kind 
of consistency for another.

(In any case, the most elegant solution is to simply not have special 
syntax for language built-in types.)

Jonathan M Davis via Digitalmars-d-announce writes:

On Thu, 29 May 2014 08:23:26 +0200
Timon Gehr via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 In any case, simply reversing the order for static array types using
 an ad-hoc rewrite rule would be a huge wart, even more severe than
 the other points you raised, and we definitely wouldn't be trading
 one kind of consistency for another.

In every other case, array dimensions are read from left-to-right, and thanks
to
    const(int)* foo;

we already threw out the whole idea of types really being read outward from
the variable name, and outside of static arrays, I don't think that we have
anything that would even care if we declared that types were always read
left-to-right. If we had always had static array dimensions be read
left-to-right in their declarations, I very much doubt that you would have
much of anyone complaining about it being inconsistent. If anything, that's
_more_ consistent with everything else. It's just that that doesn't fit with
how C/C++ compilers read types.

The only reason that I don't argue strongly for changing it is the fact that
it would break every existing program which uses multi-dimensional static
arrays, and the breakage would be easy to miss at compile time. So,
unfortunately, I think that we're stuck. But aside from arguing that it's how
C/C++ reads types, I don't see much of an argument for why it makes any sense
for static array dimensions be read from right-to-left in declarations.

- Jonathan M Davis

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

 So, unfortunately, I think that we're stuck.

You make it sound like there is a problem. ;)

 I don't see much of an argument for why it makes any sense for static 

array
 dimensions be read from right-to-left in declarations.

Language does not say anything about how people read declarations. Both 
static array dimensions and indexing are consistent currently in D.

When declaring, it is always

     Type[length]

when indexing it is always

     arr[index]

Note that there is no such thing as a multi-dimensional array in C, C++, 
or D. Hence, there is no reading from any direction; there is a simple 
and consistent syntax.

Ali

Jonathan M Davis via Digitalmars-d-announce writes:

On Thu, 29 May 2014 01:31:44 -0700
Ali Çehreli via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 05/29/2014 12:59 AM, Jonathan M Davis via Digitalmars-d-announce
 wrote:

  > So, unfortunately, I think that we're stuck.

 You make it sound like there is a problem. ;)

  > I don't see much of an argument for why it makes any sense for
  > static
 array
  > dimensions be read from right-to-left in declarations.

 Language does not say anything about how people read declarations.
 Both static array dimensions and indexing are consistent currently in
 D.

 When declaring, it is always

      Type[length]

 when indexing it is always

      arr[index]

It's consistent until you have multiple dimensions. Then you end up with the
dimensions being listed right-to-left for static array declarations and
left-to-right in all other cases.

 Note that there is no such thing as a multi-dimensional array in C,
 C++, or D. Hence, there is no reading from any direction; there is a
 simple and consistent syntax.

??? C, C++, and D all have multi-dimensional arrays. e.g.

    int a[5][6]; // C/C++
    int[6][5] a; // D
    int** a;     // C/C++
    int[][] a;   // D
    int* a[5];   // C/C++
    int[5][] a;  // D

I don't see how you could argue that they don't have multi-dimensional arrays.

- Jonathan M Davis

"Wyatt" <wyatt.epp gmail.com> writes:

On Thursday, 29 May 2014 at 10:01:17 UTC, Jonathan M Davis via 
Digitalmars-d-announce wrote:
 ??? C, C++, and D all have multi-dimensional arrays. e.g.

     int a[5][6]; // C/C++
     int[6][5] a; // D
     int** a;     // C/C++
     int[][] a;   // D
     int* a[5];   // C/C++
     int[5][] a;  // D

 I don't see how you could argue that they don't have 
 multi-dimensional arrays.

I'd guess he's contrasting with the semantics offered by 
array-oriented languages.  For example, can you determine the 
rank of those arrays programmatically in constant time?  Does the 
type system understand the shape, and can it be reshaped 
trivially?  Does an operator or function expecting rank n 
automatically lift to higher ranks?  That sort of stuff.

Maybe D does something I haven't learned about (yet) in that 
area, but I know C and C++ do not (hence the heap corruption I've 
been hunting all week).

-Wyatt

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

 On Thu, 29 May 2014 01:31:44 -0700
 Ali Çehreli via Digitalmars-d-announce

 Note that there is no such thing as a multi-dimensional array in C,
 C++, or D. Hence, there is no reading from any direction; there is a
 simple and consistent syntax.

 ??? C, C++, and D all have multi-dimensional arrays. e.g.

I think we finally see the cause of the disagreement. Those languages do 
not provide a construct called multi-dimensional array. 
Multi-dimensional arrays emerge as an application artifact when the 
programmer defines an array where the element type is an array.

Being able to create arrays of arrays by the following syntaxt does not 
change that fact. The followin syntax is just a convenience:

     auto bar = new int[][][](6, 5, 4);

      int a[5][6]; // C/C++
      int[6][5] a; // D
      int** a;     // C/C++

That is a single pointer to a single pointer. Using it as an array is 
faith-based programming but what can one do? :)

      int[][] a;   // D
      int* a[5];   // C/C++

That is an inconsistency in C and C++. See, how the element type is on 
the left of the identifier? That is not the case when the element type 
is an array. Coping from above:

      int a[5][6]; // C/C++

Do you see the problem there? It is not written with the same syntax 
when the element type was a pointer:

     int[6] a[5];    // not legal C or C++ syntax

There: C and C++ are inconsistent.

      int[5][] a;  // D

 I don't see how you could argue that they don't have 

multi-dimensional arrays.

Their specs don't have such a thing. It is possible to have arrays where 
elements are arrays but that does not make those concepts language 
constructs.

This whole issue goes well with Scott's presentation: If it is simple to 
describe then we ded right. Repeating myself, the following is all one 
needs for the array definition syntax in D:

   Type[length] identifier;

(And of course even this: 'Type[] identifier;')

Done. Now we can go wild with it to define more complex types.

That's not the case with C arrays: One needs to learn a new syntax for 
arrays of arrays there.

Ali

Jonathan M Davis via Digitalmars-d-announce writes:

On Thu, 29 May 2014 07:32:48 -0700
Ali Çehreli via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce
 wrote:
  > I don't see how you could argue that they don't have
 multi-dimensional arrays.

 Their specs don't have such a thing. It is possible to have arrays
 where elements are arrays but that does not make those concepts
 language constructs.

And how as an array of arrays _not_ a multi-dimensional array? As far as I can
tell, they're exactly the same thing just phrased differently.

- Jonathan M Davis

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 05/29/2014 08:22 AM, Jonathan M Davis via Digitalmars-d-announce wrote:

 On Thu, 29 May 2014 07:32:48 -0700
 Ali Çehreli via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 05/29/2014 03:00 AM, Jonathan M Davis via Digitalmars-d-announce
 wrote:
   > I don't see how you could argue that they don't have
 multi-dimensional arrays.

 Their specs don't have such a thing. It is possible to have arrays
 where elements are arrays but that does not make those concepts
 language constructs.

 And how as an array of arrays _not_ a multi-dimensional array? As far 

as I can
 tell, they're exactly the same thing just phrased differently.

It is not a multi-dimensional array from the point of view of the 
language spec. There is no such thing. Although, I agree that it exists 
as a concept and in human speech.

What you seem to expect from the language is the acceptance of the 
concept of multi-dimensional array as a first-class language construct. 
You want the language to have a special multi-dimensional array 
declaration syntax.

What I am saying is that since there is no such language construct, 
coming up with a special syntax just to satisfy some of the users would 
be an inconsistency in the language, which contradicts what everybody is 
looking for (Scott, you, be, etc. :) )

 - Jonathan M Davis

Ali

"Dicebot" <public dicebot.lv> writes:

On Tuesday, 27 May 2014 at 16:42:35 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/

 https://news.ycombinator.com/newest (search that page, if not 
 found click "More" and search again)

 https://www.facebook.com/dlang.org/posts/855022447844771

 https://twitter.com/D_Programming/status/471330026168651777


 Andrei

YouTube mirror : http://youtu.be/48kP_Ssg2eY