=?UTF-8?B?QWxpIMOHZWhyZWxp?=
(34/56)
May 28 2014
have some
-
Jesse Phillips
(4/7)
May 28 2014
I don't get to read the original email, but I agree with the
Walter Bright
(5/5)
May 28 2014
Some of the inconsistencies you mentioned and Brian mentioned in his tal...
-
Brian Rogoff
(4/9)
May 28 2014
Could you elaborate? Using some of the examples Brian gave, which
-
Walter Bright
(10/12)
May 28 2014
Off the top of my head:
-
Brian Schott
(33/42)
May 28 2014
Static if is not an attribute.
-
Walter Bright
(5/51)
May 28 2014
They are handled that way by the parser.
-
Dmitry Olshansky
(6/20)
May 29 2014
Static if is certainly NOT an attribute, it doesn't make any sense.
-
Brian Schott
(6/8)
May 29 2014
When issues like this come up the spec is almost always changed
-
Brian Rogoff
(17/26)
May 29 2014
I believe that the result of this policy will be that the D
-
Steven Schveighoffer
(7/30)
May 29 2014
es
-
Dmitry Olshansky
(5/34)
May 29 2014
Let it be just a declaration, as simple as that. Attributes affect other...
-
deadalnix
(9/14)
May 29 2014
in which case
-
Steven Schveighoffer
(3/18)
May 30 2014
Ugh, that is really bad. It shouldn't do that. Is that intentional?
-
Timon Gehr
(8/21)
May 31 2014
enum cond=true;
-
Steven Schveighoffer
(4/26)
Jun 02 2014
OK, so the original premise is not true? I was assuming deadalnix was
-
Walter Bright
(12/33)
May 31 2014
Yes. Semantic scope and lexical scope are different things. The ':' thin...
-
Steven Schveighoffer
(9/46)
Jun 02 2014
deadalnix's suggestion, at least to me, was that currently the compiler ...
-
Walter Bright
(5/6)
May 29 2014
Yes, it does make sense. It was not an accident that the frontend treats...
Dmitry Olshansky
(20/62)
May 29 2014
This is gross oversimplification of the matter. There is no more
-
Walter Bright
(8/10)
May 29 2014
Yes. Attempting to hide the fact that strings are UTF-8 is just doomed. ...
-
Regan Heath
(9/18)
May 30 2014
And it's the right choice. 4 of the 7 billion people in the world today...
Jonathan M Davis via Digitalmars-d-announce
(93/98)
May 28 2014
Okay. That seriously got munged. Let's try that again...
Jonathan M Davis via Digitalmars-d-announce
(12/17)
May 28 2014
On Wed, 28 May 2014 16:07:08 -0700
-
Timon Gehr
(8/26)
May 28 2014
I think this is not a point about "consistency", but about intuition.
Dicebot
(3/9)
May 29 2014
YouTube mirror : http://youtu.be/48kP_Ssg2eY
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
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?
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…
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.
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.
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/
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
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.)
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
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.
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
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.
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.
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.
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
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!
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."
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
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.
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...
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
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.
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
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."
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.)
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
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.
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.
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.
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.
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
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
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
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.
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.
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.
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
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;
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).
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.
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.
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.
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;
}
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.
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.
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.
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
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)?
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.
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
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.
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.
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
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
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.
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
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.
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
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.
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/
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/
<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/>
<digitalmars-d-announce puremagic.com> wrote:<br/>
<br/>
> <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/>
><br/>
> <a href="https://news.ycombinator.com/newest"
target="_blank">https://news.ycombinator.com/newest</a> (search that page, if
not found<br/>
> click "More" and search again)<br/>
><br/>
> <a href="https://www.facebook.com/dlang.org/posts/855022447844771"
target="_blank">https://www.facebook.com/dlang.org/posts/855022447844771</a><br/>
><br/>
> <a href="https://twitter.com/D_Programming/status/471330026168651777"
target="_blank">https://twitter.com/D_Programming/status/471330026168651777</a><br/>
<br/>
inconsistencies that Scott describes for C++, but we do definitely have
some<br/>
of our own. The ones that come to mind at the moment are:<br/>
<br/>
1. The order of the dimensions of multi-dimensional static arrays is
backwards<br/>
in comparison to what most everyone expects.<br/>
<br/>
int[4][5][6] foo;<br/>
<br/>
is the same as<br/>
<br/>
int foo[6][5][4];<br/>
<br/>
and has the same dimensions as<br/>
<br/>
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/>
const(int)* foo;<br/>
<br/>
<br/>
(int)const* foo;<br/>
<br/>
I think that we threw that particular bit of consistency with C/C++ out the<br/>
window, and we really should have just made static array dimensions be read<br/>
from left-to-right.<br/>
<br/>
doing<br/>
so would cause silent breakage (or at minimum, would be silent until<br/>
RangeErrors were thrown at runtime).<br/>
<br/>
<br/>
<br/>
auto foo = new int[5];<br/>
<br/>
is the same as<br/>
<br/>
auto foo = new int[](5);<br/>
<br/>
because<br/>
<br/>
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/>
auto foo = new int[][][](4, 5, 6);<br/>
<br/>
IMHO, we should have made it illegal to have dynamic array dimensions
inside<br/>
change<br/>
of<br/>
existing code would be broken - especially because so many people put the<br/>
array dimensions between the brackets for single-dimension dynamic arrays.<br/>
<br/>
<br/>
3. const, immutable, and inout on the left-hand side of a function
declaration<br/>
are unfortunately legal. This inevitably trips people up, because they
think<br/>
that the attribute applies to the return type, when it applies to the
function<br/>
itself. This is to make the function attributes consistent, because all of<br/>
bad<br/>
practice to ever put any attribute on the left-hand side which could apply
to<br/>
the return type, because it looks like a bug. If we just made it illegal
for<br/>
those attributes to go on the left, the problem would be solved, and the<br/>
result would be far less confusing and bug-prone. I think that we can make<br/>
them<br/>
no the left-hand side), but AFAIK, Walter is against the idea.<br/>
<br/>
<br/>
4. There are some cases (such as with static constructors and unittest
blocks)<br/>
remember<br/>
even<br/>
seasoned D programmers from time to time.<br/>
<br/>
<br/>
5. The fact that pure is called pure is very problematic at this point as
far<br/>
as explaining things to folks goes. We should probably consider renaming it
to<br/>
well<br/>
given the amount of breakage involved. It _does_ require a lot of
explaining<br/>
though.<br/>
<br/>
<br/>
6. The situation with ranges and string is kind of ugly, with them being<br/>
to<br/>
this is, since treating them as ranges of code units promotes efficiency
but<br/>
makes code more error-prone, whereas treating them as ranges of graphemes<br/>
would just cost too much. Ranges of code points is _mostly_ correct but
still<br/>
incorrect and _more_ efficient than graphemes but still quite a bit less<br/>
worst<br/>
of both worlds. The current situation causes inconsistencies with
everything<br/>
else (forcing us to use isNarrowString all over the place) and definitely<br/>
requires frequent explaining, but it does prevent some classes of problems.<br/>
this<br/>
treating<br/>
them as ranges of code units and then have wrappers for ranges of code
points<br/>
or graphemes. It seems like the current situation promotes either using<br/>
ubyte[] (if you care about efficiency) or the new grapheme facilities in<br/>
std.uni if you care about correctness, whereas just using strings as ranges
of<br/>
of<br/>
willing<br/>
have bugs in the areas where operating at the code point level is
incorrect.<br/>
<br/>
<br/>
7. There are several minor inconsistencies with local imports and nested<br/>
functions in comparison to module-level imports or free functions, and I
think<br/>
be.<br/>
<br/>
<br/>
are<br/>
others, and this post is already probbaly too long). So, we definitely have<br/>
off<br/>
than C++ in that regard. Fortunately, while Phobos still has some naming<br/>
issues, a lot of the naming inconsistencies were sorted out a couple of
years<br/>
ago, and we have solved a number of other inconsistencies in the language
and<br/>
number<br/>
of inconsistencies that we have rather than increasing them. But we should<br/>
look at reducing them further if we can and should _definitely_ keep an eye<br/>
out for areas where more inconsistencies could creep in.<br/>
<br/>
- Jonathan M Davis</div></div></body></html>
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
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.
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.
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?
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.
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
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
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
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.
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.
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
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
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
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.
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
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?
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
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.
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
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?
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
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
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: {
...
}
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
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.
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/
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
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...
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
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.)
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
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
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
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
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
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
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
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