Re: D needs...
On Monday, 18 May 2015 at 21:51:49 UTC, Namespace wrote: Knee-jerk response: if no return attribute on a function it should be safe to bind rvalues to ref parameters. Of course that's impractical as a default so explicit auto ref would be needed. -- Andrei Would it be to hasty if someone would start implementing auto ref for non-templates right now? Or should a more experienced user do that? Just in case I can contribute somehow. I took the liberty to begin with an implementation. Thanks to Kenjiis work, it was not too difficult, I had to adjust only the changes on the new code base: https://github.com/Dgame/dmd/tree/auto-ref-for-non-templates Maybe this could be reviewed as soon as 'return ref' is fully implemented.
Re: D needs...
On Thu, 21 May 2015 17:19:27 + Namespace via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 May 2015 at 15:10:14 UTC, Daniel Kozak wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ negation of attributes: https://github.com/Kozzi11/dmd/tree/rever_attr No final(false)? :( My first local version have final(bool), but after some thoughts I end up with !final. It is little bit easier to implement and efficient.
Re: D needs...
On Thu, 21 May 2015 17:19:27 + Namespace via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 May 2015 at 15:10:14 UTC, Daniel Kozak wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ negation of attributes: https://github.com/Kozzi11/dmd/tree/rever_attr No final(false)? :( I will probably implement all variants (final!bool, !final, final(bool), default), if I have a enought spare time.
Re: D needs...
On Thursday, 21 May 2015 at 19:47:56 UTC, Daniel Kozak wrote: On Thu, 21 May 2015 19:38:17 + Meta via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 May 2015 at 17:47:02 UTC, Daniel Kozak wrote: I will probably implement all variants (final!bool, !final, final(bool), default), if I have a enought spare time. Any plans on turning it into a PR when you're done? Not so far. But if I will be satisfied with any version I could try to make PR. That would be really kind of you. Negation of attributes and rvalue references are the things I miss the most.
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ negation of attributes: https://github.com/Kozzi11/dmd/tree/rever_attr
Re: D needs...
On Thursday, 21 May 2015 at 17:47:02 UTC, Daniel Kozak wrote: On Thu, 21 May 2015 17:19:27 + Namespace via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 May 2015 at 15:10:14 UTC, Daniel Kozak wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ negation of attributes: https://github.com/Kozzi11/dmd/tree/rever_attr No final(false)? :( I will probably implement all variants (final!bool, !final, final(bool), default), if I have a enought spare time. All right. I'm curious. ;)
Re: D needs...
On Thu, 21 May 2015 19:38:17 + Meta via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 May 2015 at 17:47:02 UTC, Daniel Kozak wrote: I will probably implement all variants (final!bool, !final, final(bool), default), if I have a enought spare time. Any plans on turning it into a PR when you're done? Not so far. But if I will be satisfied with any version I could try to make PR.
Re: D needs...
On Thursday, 21 May 2015 at 17:47:02 UTC, Daniel Kozak wrote: I will probably implement all variants (final!bool, !final, final(bool), default), if I have a enought spare time. Any plans on turning it into a PR when you're done?
Re: D needs...
On Thursday, 21 May 2015 at 15:10:14 UTC, Daniel Kozak wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ negation of attributes: https://github.com/Kozzi11/dmd/tree/rever_attr No final(false)? :(
Re: D needs...
Knee-jerk response: if no return attribute on a function it should be safe to bind rvalues to ref parameters. Of course that's impractical as a default so explicit auto ref would be needed. -- Andrei Would it be to hasty if someone would start implementing auto ref for non-templates right now? Or should a more experienced user do that? Just in case I can contribute somehow.
Re: D needs...
What about mutable references to immutable/shared/const classes?
class A {}
immutable(A)[int] aa;
aa[1] = new immutable A;// doesn't compile
Rebindable!(immutable(A))[int]; // looks like ugly shamefull
workaround.
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Nice! Especially the discussion links. Would be good to see a final-by-default summary too.
Re: D needs...
On Tue, 12 May 2015 06:39:09 + ponce via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Nice! Especially the discussion links. Would be good to see a final-by-default summary too. There would be too much discussion links ;-)
Re: D needs...
On Tuesday, 12 May 2015 at 06:39:10 UTC, ponce wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Nice! Especially the discussion links. Would be good to see a final-by-default summary too. As you wish: http://dgame.github.io/dneeds/#final-by-default
Re: D needs...
On Monday, 11 May 2015 at 17:49:32 UTC, Namespace wrote: I've read DIP69 and there were a few lines about scope ref. But I'm not sure whether I understand everything correct (because there is no concrete application example for my case): will DIP69 create the possibility to pass rvalues and lvalues alike to a function without the abuse of templates? Or did I got that wrong? DIP69 is more or less dead, we're going with a variation of DIP25 (although that one still has holes). As for rvalue ref, it would enable them safely, but it is not a part of that DIP (or DIP69, AFAICS).
Re: D needs...
On Tuesday, 12 May 2015 at 09:31:13 UTC, Marc Schütz wrote: On Monday, 11 May 2015 at 17:49:32 UTC, Namespace wrote: I've read DIP69 and there were a few lines about scope ref. But I'm not sure whether I understand everything correct (because there is no concrete application example for my case): will DIP69 create the possibility to pass rvalues and lvalues alike to a function without the abuse of templates? Or did I got that wrong? DIP69 is more or less dead, we're going with a variation of DIP25 (although that one still has holes). As for rvalue ref, it would enable them safely, but it is not a part of that DIP (or DIP69, AFAICS). And I thought for a moment, we have a solution in sight... :)
Re: D needs...
On 5/12/15 3:09 AM, Namespace wrote: On Tuesday, 12 May 2015 at 09:31:13 UTC, Marc Schütz wrote: On Monday, 11 May 2015 at 17:49:32 UTC, Namespace wrote: I've read DIP69 and there were a few lines about scope ref. But I'm not sure whether I understand everything correct (because there is no concrete application example for my case): will DIP69 create the possibility to pass rvalues and lvalues alike to a function without the abuse of templates? Or did I got that wrong? DIP69 is more or less dead, we're going with a variation of DIP25 (although that one still has holes). As for rvalue ref, it would enable them safely, but it is not a part of that DIP (or DIP69, AFAICS). And I thought for a moment, we have a solution in sight... :) Knee-jerk response: if no return attribute on a function it should be safe to bind rvalues to ref parameters. Of course that's impractical as a default so explicit auto ref would be needed. -- Andrei
Re: D needs...
Knee-jerk response: if no return attribute on a function it should be safe to bind rvalues to ref parameters. Of course that's impractical as a default so explicit auto ref would be needed. -- Andrei yay, I'm glad to hear that. :)
Re: D needs...
On Mon, 11 May 2015 12:24:34 +
weaselcat via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it gets
forgotten sometimes and the theme disappears into oblivion
(for a few months :P). To prevent this, I've collected some
hot-discussed themes, their history and their current state. I
hope this helps to avoid unnecessary discussions in the future
and finally cut off these issues (either with an official
decision Nope, keep as it is or with an implementation).
I've tried to stay as objective as possible, but if something
seems to be too subjective, please let me know, so I can fix
it.
http://dgame.github.io/dneeds/
Thanks. Many programmers find fault with this problem:
No problem. But if you have more elements it could be annoying
to count them. That's why some D users wanted that the compiler
does that for them.
int[$] c = [1, 2, 3]; // the compiler detects the dollar and
count the elements for us
+1, I have to go review why this was removed. It's annoying that
I have to manually count static arrays.
import std.stdio;
@safe @property auto static_array()
{
static struct _static_array
{
@safe
@property
T[n] s(T, size_t n)(auto ref T[n] values) { return values; }
T[0][n] opIndex(size_t n = T.length, T...)(T items)
{
typeof(return) arr;
foreach (index,item; items)
arr[index] = item;
return (values) { return values; }(arr);//s!(T[0], n)(arr);
}
}
return _static_array();
}
void main() {
auto sa = static_array[4,5,7];
writeln(sa);
}
Re: D needs...
On Monday, 11 May 2015 at 12:53:26 UTC, John Colvin wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ I think in auto length for fixed-length arrays you want auto c = [1, 2, 3].s; instead of int[] c = [1, 2, 3].s; in order to be as close to the int[$] idea as possible. Both work, but you may be right... :)
Re: D needs...
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Thanks. Many programmers find fault with this problem: No problem. But if you have more elements it could be annoying to count them. That's why some D users wanted that the compiler does that for them. int[$] c = [1, 2, 3]; // the compiler detects the dollar and count the elements for us +1, I have to go review why this was removed. It's annoying that I have to manually count static arrays.
D needs...
Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Thanks. Many programmers find fault with this problem: No problem. But if you have more elements it could be annoying to count them. That's why some D users wanted that the compiler does that for them. int[$] c = [1, 2, 3]; // the compiler detects the dollar and count the elements for us
Re: D needs...
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Thanks. Many programmers find fault with this problem: No problem. But if you have more elements it could be annoying to count them. That's why some D users wanted that the compiler does that for them. int[$] c = [1, 2, 3]; // the compiler detects the dollar and count the elements for us Yeah, but the given example shows you an alternative.
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ I think in auto length for fixed-length arrays you want auto c = [1, 2, 3].s; instead of int[] c = [1, 2, 3].s; in order to be as close to the int[$] idea as possible.
Re: D needs...
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote:
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to
the vomit. If something is agreed, it gets forgotten sometimes
and the
theme disappears into oblivion (for a few months :P). To
prevent this,
I've collected some hot-discussed themes, their history and
their
current state. I hope this helps to avoid unnecessary
discussions in the
future and finally cut off these issues (either with an
official
decision Nope, keep as it is or with an implementation).
I've tried to stay as objective as possible, but if something
seems to
be too subjective, please let me know, so I can fix it.
http://dgame.github.io/dneeds/
int[] test() {
return [1, 2, 3].s; // this is stack allocated
}
That's not a very compelling use case. :o)
The stack memory goes right out of scope after having been
sliced.
Should be better now. ;)
http://dgame.github.io/dneeds/#static-array-literal
Re: D needs...
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something similar.
There are some themes in D which come up regulary and are discussed to
the vomit. If something is agreed, it gets forgotten sometimes and the
theme disappears into oblivion (for a few months :P). To prevent this,
I've collected some hot-discussed themes, their history and their
current state. I hope this helps to avoid unnecessary discussions in the
future and finally cut off these issues (either with an official
decision Nope, keep as it is or with an implementation).
I've tried to stay as objective as possible, but if something seems to
be too subjective, please let me know, so I can fix it.
http://dgame.github.io/dneeds/
int[] test() {
return [1, 2, 3].s; // this is stack allocated
}
That's not a very compelling use case. :o)
The stack memory goes right out of scope after having been sliced.
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: http://dgame.github.io/dneeds/ There seems to be some overlap with some existing wiki pages: http://wiki.dlang.org/Language_design_discussions http://wiki.dlang.org/Language_issues
Re: D needs...
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote:
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to
the vomit. If something is agreed, it gets forgotten sometimes
and the
theme disappears into oblivion (for a few months :P). To
prevent this,
I've collected some hot-discussed themes, their history and
their
current state. I hope this helps to avoid unnecessary
discussions in the
future and finally cut off these issues (either with an
official
decision Nope, keep as it is or with an implementation).
I've tried to stay as objective as possible, but if something
seems to
be too subjective, please let me know, so I can fix it.
http://dgame.github.io/dneeds/
int[] test() {
return [1, 2, 3].s; // this is stack allocated
}
That's not a very compelling use case. :o)
The stack memory goes right out of scope after having been
sliced.
Argh, of course. The return type must be auto. :)
Re: D needs...
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote: The stack memory goes right out of scope after having been sliced. I hate that static arrays are implicitly sliced. It leads to common memory safety bugs in places like that.
Re: D needs...
On Monday, 11 May 2015 at 13:51:59 UTC, Vladimir Panteleev wrote: On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: http://dgame.github.io/dneeds/ There seems to be some overlap with some existing wiki pages: http://wiki.dlang.org/Language_design_discussions http://wiki.dlang.org/Language_issues Nice, I've never seen these pages before. But I have the feeling that I'm not the only one. These issues should have top priority and these pages should be more visible for other users.
Re: D needs...
I've read DIP69 and there were a few lines about scope ref. But I'm not sure whether I understand everything correct (because there is no concrete application example for my case): will DIP69 create the possibility to pass rvalues and lvalues alike to a function without the abuse of templates? Or did I got that wrong?
Re: D needs...
D needs manpower ... such a shame there's so few of us... On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision Nope, keep as it is or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Sat, 31 May 2014 18:56:17 -0400, Timon Gehr timon.g...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Sat, 31 May 2014 19:27:08 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
On Thu, 29 May 2014 21:15:21 -0400, deadalnix deadal...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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;
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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).
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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?
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On 5/30/2014 5:37 AM, Steven Schveighoffer wrote:
On Thu, 29 May 2014 21:15:21 -0400, deadalnix deadal...@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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Tue, 27 May 2014 22:40:00 +0100, Walter Bright newshou...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 20:40:10 +0100, Walter Bright newshou...@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/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 21:15:21 -0400, deadalnix deadal...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.)
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
[OT] Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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...
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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...
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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;
}
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: [OT] Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton alix.dot.pex...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Wed, 28 May 2014 22:38:55 -0400, Jesse Phillips
jesse.k.phillip...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On 2014-05-29 03:29, 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); IMO, it's the dynamic array creation syntax that's weird here. The static array syntax is sensible, easy to explain, and consistent with reading the type left to right. I've never used the syntax for creating a multidimensional dynamic array, so I was frankly surprised to see it worked that way. -- Simen
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 10:20:39 -0400, Jesse Phillips jesse.k.phillip...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 13:12:24 -0400, Walter Bright
newshou...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
dmitry.o...@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.
-Steve
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
29-May-2014 23:06, Steven Schveighoffer пишет:
On Thu, 29 May 2014 14:11:27 -0400, Dmitry Olshansky
dmitry.o...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 15:24:06 -0400, Dmitry Olshansky dmitry.o...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Thu, 29 May 2014 15:29:31 -0400, Walter Bright newshou...@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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: [OT] Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On 5/29/2014 9:14 AM, Steven Schveighoffer wrote: On Thu, 29 May 2014 04:57:14 -0400, Alix Pexton alix.dot.pex...@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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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: {
...
}
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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=om7O0MFkmpwfeature=kp
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
On Wed, 28 May 2014 04:48:09 +, 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.
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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.
Re: Scott Meyers' DConf 2014 keynote 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/
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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=om7O0MFkmpwfeature=kp At least the Queen and I agree on something!
Re: Scott Meyers' DConf 2014 keynote The Last Thing D Needs
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 weve 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 didnt 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 dont 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. Were 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, its just confusing, because auto foo = new int[4][5][6]; does _not_ declare a multi-dimensional dynimac 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 dont know if we can change that. It wouldnt 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 its 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 its 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 dont remember the reasons for it, but its 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 Im 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 dont 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, its kind of like its 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 dont know. I used to be in favor of the current situation, but at this point, if we could change it, I think that Id 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
