www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"

next sibling parent 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?
May 27 2014
prev sibling next sibling parent reply "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…
May 27 2014
next sibling parent "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.
May 27 2014
prev sibling parent reply 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.
May 27 2014
next sibling parent 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/
May 27 2014
prev sibling parent "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
May 27 2014
prev sibling next sibling parent reply "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.)
May 27 2014
next sibling parent reply "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
May 27 2014
parent reply "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.
May 27 2014
next sibling parent "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
May 27 2014
prev sibling parent reply "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.
May 27 2014
parent reply "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.
May 27 2014
parent reply 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.
May 27 2014
next sibling parent reply "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
May 28 2014
parent 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!
May 28 2014
prev sibling next sibling parent reply "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."
May 28 2014
next sibling parent =?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
May 28 2014
prev sibling next sibling parent "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.
May 28 2014
prev sibling parent reply 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...
May 29 2014
parent reply "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
May 29 2014
parent 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.
May 29 2014
prev sibling parent "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
May 30 2014
prev sibling parent reply 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."
May 27 2014
parent reply "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.)
May 27 2014
parent 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
May 27 2014
prev sibling next sibling parent reply "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.
May 27 2014
next sibling parent reply 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.
May 27 2014
parent reply "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.
May 27 2014
next sibling parent reply 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.
May 28 2014
parent reply "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
May 29 2014
next sibling parent reply 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
May 30 2014
parent reply 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
May 30 2014
parent "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.
May 30 2014
prev sibling next sibling parent reply "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.
May 30 2014
parent "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.
May 30 2014
prev sibling next sibling parent 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
May 30 2014
prev sibling parent reply "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;
May 31 2014
parent reply "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).
May 31 2014
parent reply "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.
May 31 2014
parent "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.
Jun 01 2014
prev sibling next sibling parent 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.
May 28 2014
prev sibling parent reply "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; }
May 29 2014
parent "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.
May 29 2014
prev sibling next sibling parent reply 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.
May 28 2014
parent reply "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.
May 28 2014
parent 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
May 29 2014
prev sibling parent reply "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)?
May 28 2014
next sibling parent "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.
May 29 2014
prev sibling next sibling parent reply 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
May 29 2014
parent reply "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.
May 29 2014
next sibling parent 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.
May 29 2014
prev sibling parent 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
May 29 2014
prev sibling parent reply "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
May 29 2014
next sibling parent reply "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.
May 29 2014
parent "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
May 29 2014
prev sibling parent reply 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.
May 29 2014
parent reply "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
May 29 2014
parent 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.
May 29 2014
prev sibling next sibling parent reply "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/
May 28 2014
parent "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/
May 28 2014
prev sibling next sibling parent reply 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/>
Fortunately, for the most part, I think that we&#39;ve avoided the types of<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/>
and didn&#39;t allow<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/>
Unfortunately, I don&#39;t think that we can fix that at this point, because
doing<br/>
so would cause silent breakage (or at minimum, would be silent until<br/>
RangeErrors were thrown at runtime).<br/>
<br/>
<br/>
2. We&#39;re inconsistent with dynamic array dimensions.<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/>
but once you get into multi-dimensional arrays, it&#39;s just confusing,
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/>
of the brackets rather than the parens, but I don&#39;t know if we can
change<br/>
that. It wouldn&#39;t be silent breakage, but it _would_ make it so that a lot
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/>
the others can go on either side, but the result is that it&#39;s essentially
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/>
that change with minimal breakage (since it&#39;s already bad practice to put
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/>
that the attributes have to go on the left for some reason. I don&#39;t
remember<br/>
the reasons for it, but it&#39;s an inconsistency which definitely trips up
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/>
something like  noglobal, but I&#39;m not sure that that would go over very
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/>
treated as ranges of code points. I don&#39;t know what the correct solution
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/>
efficient than code units. So, it&#39;s kind of like it&#39;s got the best and
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/>
So, I don&#39;t know. I used to be in favor of the current situation, but at
this<br/>
point, if we could change it, I think that I&#39;d argue in faver of just
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/>
dchar is probably a bad idea unless you just don&#39;t want to deal with any
of<br/>
the Unicode stuff, don&#39;t care all that much about efficiency, and are
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/>
that some of those should be fixed, but I&#39;m not sure that all of them can
be.<br/>
<br/>
<br/>
That&#39;s what I can think of at the moment (though I&#39;m sure that there
are<br/>
others, and this post is already probbaly too long). So, we definitely have<br/>
our own consistency issues, but I do think that we&#39;re still far better
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/>
library over time, so if anything, we&#39;ve probably been _reducing_ the
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>
May 28 2014
next sibling parent reply =?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
May 28 2014
parent "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.
May 28 2014
prev sibling next sibling parent reply 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.
May 28 2014
parent reply "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?
May 28 2014
parent reply 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.
May 28 2014
next sibling parent reply "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
May 28 2014
parent 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
May 28 2014
prev sibling parent reply 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
May 29 2014
next sibling parent reply "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.
May 29 2014
parent "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.
May 29 2014
prev sibling next sibling parent reply "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
May 29 2014
next sibling parent reply 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
May 29 2014
parent "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
May 29 2014
prev sibling parent reply "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.
May 29 2014
parent reply "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
May 30 2014
next sibling parent reply 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?
May 31 2014
parent "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
Jun 02 2014
prev sibling parent reply 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.
May 31 2014
parent "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
Jun 02 2014
prev sibling parent reply 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?
May 29 2014
next sibling parent "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
May 29 2014
prev sibling parent reply 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
May 29 2014
parent 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: { ... }
May 29 2014
prev sibling parent reply 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
May 29 2014
parent reply 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.
May 29 2014
parent "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/
May 30 2014
prev sibling next sibling parent reply 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
May 28 2014
parent "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...
May 29 2014
prev sibling next sibling parent reply 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
May 28 2014
parent reply 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.)
May 28 2014
parent reply 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
May 29 2014
parent reply =?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
May 29 2014
parent reply 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
May 29 2014
next sibling parent "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
May 29 2014
prev sibling parent reply =?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
May 29 2014
parent reply 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
May 29 2014
parent =?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
May 29 2014
prev sibling parent "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
May 29 2014