www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The current status of D?

reply Buk <D.20.browseruk xoxy.net> writes:
Simple question, though not necessarily a simple answer:

Is D ready for prime time?

Sub-questions:

1. How stable is the language specification?
2. How stable is the language implementation?
3. How stable are the standard library specifications?
4. How stable are the standard library implantations?

The last time I looked was just after the D1/D2 split, and much of the design
was being revamped and the rate of changes and deprecations was (IMO) too high
to consider its use for complex, multi-developer projects.

Looking around the docs here, I see that some of the libraries are due for
deprecation early next year. Barring surprises, are they likely to be the last
major changes?

Thanks for your time, buk.
Dec 01 2011
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
On Thu, 1 Dec 2011 21:24:40 +0000 (UTC)
Buk <D.20.browseruk xoxy.net> wrote:


 Simple question, though not necessarily a simple answer:
 
 Is D ready for prime time?


This is a hard question indeed. It is ready to be used, and even in
production, but not blindly.
 

 Sub-questions:
 
 1. How stable is the language specification?


The specification shouldn't change, but since there is no full
implementation of D, really bad choices could get changed.

Also, the website is not the best at being up-to-date, submit bug
reports. The D Programming language by Andrei is the official word on
what D v2 does.


 2. How stable is the language implementation?


There is a bug here and there, it is in good shape but misses some
features.


 3. How stable are the standard library specifications?


Umm, under quite a bit of change and not really complete.


 4. How stable are the standard library implantations?


There are some very stable parts but others which are changing.

Pages of interest:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel
http://www.prowiki.org/wiki4d/wiki.cgi?ReviewQueue
Dec 01 2011
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/1/2011 1:24 PM, Buk wrote:

 Is D ready for prime time?


Idk, the fact that I run across transitive-const-related situations like
stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d 
<http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d>
makes it so I can't use D at all, since it's hard to go around these 
issues sometimes.

As long as the language suffers from const issues, I think, it won't be 
ready for prime time, since 'const' is supposed to be one of its highest 
strengths, and at the same time it's part-broken.
Dec 01 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/02/2011 08:25 AM, Mehrdad wrote:

 On 12/1/2011 1:24 PM, Buk wrote:

 Is D ready for prime time?


 Idk, the fact that I run across transitive-const-related situations like
 stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d
 <http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d>

 makes it so I can't use D at all, since it's hard to go around these
 issues sometimes.


You have to be joking.


 As long as the language suffers from const issues, I think, it won't be
 ready for prime time, since 'const' is supposed to be one of its highest
 strengths, and at the same time it's part-broken.


Its design is not broken and the implementation has almost caught up. 
(there are some obscure implicit conversions that should be allowed and 
some that shouldn't that DMD does not get right yet.) Please give 
objective information (as Jesse Phillips did.)

Regarding you little problem, why did you think using inout would not 
work for classes? I just posted an answer on SO that shows that it does.

BTW, I think most features in D are 'supposed to be one of its highest 
strengths', by that measure.
Dec 02 2011
next sibling parent Mehrdad <wfunction hotmail.com> writes:
On 12/2/2011 4:25 AM, Timon Gehr wrote:

 You have to be joking.


I wasn't, but if it makes you feel better then you can think of it that way.


 Its design is not broken and the implementation has almost caught up. 
 (there are some obscure implicit conversions that should be allowed 
 and some that shouldn't that DMD does not get right yet.) Please give 
 objective information (as Jesse Phillips did.)


I can't see how the question I posted was subjective, but thanks for the 
suggestion...


 Regarding you little problem, why did you think using inout would not 
 work for classes? I just posted an answer on SO that shows that it does.


Because your example also used inout for opSlice()   (in fact, for 
pretty much everything), something that the original answer had not 
suggested and which I never envisioned I should do.
I guess the documentation should be filled with more/better examples? 
That was rather obscure.


 BTW, I think most features in D are 'supposed to be one of its highest 
 strengths', by that measure.


lol, http://en.wikipedia.org/wiki/Markov%27s_inequality says this is 
impossible.
-------


 I never envisioned how inout would work on a ctor.


Yeah, neither did I (and especially not the way it was used on opSlice, 
the way it's used just like 'const'), so I just thought it was 
impossible. IMO if the documentation doesn't explain these, not everyone 
will figure things out on their own...


 inout has fixed many of these issues.  There is still work to be 


done, but I think we're in a much better place than we were before.
Yeah, it looks fine when you use inout on everything (instead of const), 
thanks to both!
Dec 02 2011
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
Actually, regarding my "little problem", why does this given an 
error/what's the proper way to fix it?

     class C(T) { inout this(inout(T)) { } }
     C!T slice(T)(auto ref T c) { return new C!T(c); }
     void main() { [1, 2, 3, 4, 5].slice(); }

     //Test.d(2): Error: cannot implicitly convert expression (new 
C(items)) of type inout(C) to Test.C!(int[]).C
Dec 02 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/02/2011 05:13 PM, Mehrdad wrote:

 Actually, regarding my "little problem", why does this given an
 error/what's the proper way to fix it?

 class C(T) { inout this(inout(T)) { } }
 C!T slice(T)(auto ref T c) { return new C!T(c); }
 void main() { [1, 2, 3, 4, 5].slice(); }

 //Test.d(2): Error: cannot implicitly convert expression (new C(items))
 of type inout(C) to Test.C!(int[]).C


1. File a bug. inout is apparently not resolved properly by DMD in this 
case.

2. Apply this workaround to make the compiler shut up (and probably to 
make your code less bloated by extraneous template instances as well :o)):

class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { [1, 2, 3, 4, 5].slice(); }
Dec 02 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/2/2011 9:38 AM, Timon Gehr wrote:

 On 12/02/2011 05:13 PM, Mehrdad wrote:

 Actually, regarding my "little problem", why does this given an
 error/what's the proper way to fix it?

 class C(T) { inout this(inout(T)) { } }
 C!T slice(T)(auto ref T c) { return new C!T(c); }
 void main() { [1, 2, 3, 4, 5].slice(); }

 //Test.d(2): Error: cannot implicitly convert expression (new C(items))
 of type inout(C) to Test.C!(int[]).C


 1. File a bug. inout is apparently not resolved properly by DMD in 
 this case.


http://d.puremagic.com/issues/show_bug.cgi?id=7053


 2. Apply this workaround to make the compiler shut up (and probably to 
 make your code less bloated by extraneous template instances as well 
 :o)):

 class C(T) { inout this(inout(T)) { } }
 inout(C!T) slice(T)(inout T c){ return new C!T(c); }
 void main() { [1, 2, 3, 4, 5].slice(); }


That just propagates it up the stack, though...
Dec 02 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/02/2011 09:57 PM, Mehrdad wrote:

 On 12/2/2011 9:38 AM, Timon Gehr wrote:

 On 12/02/2011 05:13 PM, Mehrdad wrote:

 Actually, regarding my "little problem", why does this given an
 error/what's the proper way to fix it?

 class C(T) { inout this(inout(T)) { } }
 C!T slice(T)(auto ref T c) { return new C!T(c); }
 void main() { [1, 2, 3, 4, 5].slice(); }

 //Test.d(2): Error: cannot implicitly convert expression (new C(items))
 of type inout(C) to Test.C!(int[]).C


 1. File a bug. inout is apparently not resolved properly by DMD in
 this case.


 http://d.puremagic.com/issues/show_bug.cgi?id=7053


 2. Apply this workaround to make the compiler shut up (and probably to
 make your code less bloated by extraneous template instances as well
 :o)):

 class C(T) { inout this(inout(T)) { } }
 inout(C!T) slice(T)(inout T c){ return new C!T(c); }
 void main() { [1, 2, 3, 4, 5].slice(); }


 That just propagates it up the stack, though...


It does not, otherwise I would not have called it a workaround. It seems 
only to be a problem for class constructors:

class C(T) { inout this(inout(T)) { } }
inout(C!T) slice(T)(inout T c){ return new C!T(c); }
void main() { static assert(!is(typeof([1, 2, 3, 4, 5].slice())==inout)); }
Dec 02 2011
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
... another bug with inout():

     import std.stdio;
     //Error: inout on parameter means inout must be on return type as 
well  (???)
     class C { inout(C) foo() inout { writeln(this); return this; } }
     void main() { }

IMHO, 'inout' is fundamentally flawed: it should not act like a type 
constructor at all, because that makes no sense. But it seems to be what 
it's doing here...


So no, I wasn't joking -- getting around these problems gets pretty 
annoying (getting rid of one causes another), as trivial as you may make 
them out to be. I love D's features as well, but if I have to spend a 
nontrivial amount of time working around the D compiler, then I probably 
wouldn't use the D compiler at all.
Dec 02 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Dec 2011 11:28:45 -0500, Mehrdad <wfunction hotmail.com> wrote:


 ... another bug with inout():

      import std.stdio;
      //Error: inout on parameter means inout must be on return type as  
 well  (???)
      class C { inout(C) foo() inout { writeln(this); return this; } }
      void main() { }

 IMHO, 'inout' is fundamentally flawed: it should not act like a type  
 constructor at all, because that makes no sense. But it seems to be what  
 it's doing here...


inout must participate in the return value or there is no point in using  
inout (use const instead).

However, one thing we did not anticipate is how to do IFTI with inout  
values.  There is an open bug report on this:  
http://d.puremagic.com/issues/show_bug.cgi?id=6809

You can work around by explicitly instantiating with const, or by doing:

writeln(cast(const)this);


 So no, I wasn't joking -- getting around these problems gets pretty  
 annoying (getting rid of one causes another), as trivial as you may make  
 them out to be. I love D's features as well, but if I have to spend a  
 nontrivial amount of time working around the D compiler, then I probably  
 wouldn't use the D compiler at all.


This is understandable.  We have some major issues to resolve still.  But  
if you don't hit those, it's reasonable to work with.

-Steve
Dec 02 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/2/2011 10:41 AM, Steven Schveighoffer wrote:

 You can work around by explicitly instantiating with const, or by doing:

 writeln(cast(const)this);


I'm trying to avoid cast at all costs in D (even more than in C++), 
since D's casts are more dangerous than C++ casts. :\
Thanks for the suggestion though! :)
Dec 02 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Dec 2011 15:51:32 -0500, Mehrdad <wfunction hotmail.com> wrote:


 On 12/2/2011 10:41 AM, Steven Schveighoffer wrote:

 You can work around by explicitly instantiating with const, or by doing:

 writeln(cast(const)this);


 I'm trying to avoid cast at all costs in D (even more than in C++),  
 since D's casts are more dangerous than C++ casts. :\
 Thanks for the suggestion though! :)


It's understandable.  In this case, you are doing something that should be  
able to be implicit, in order to force IFTI to interpret a certain way.

In all reality, writeln should const-ify all its args, but it can't  
because phobos isn't const correct yet.

Another workaround which avoids casts is this:

const tmp = this;
writeln(tmp);

-Steve
Dec 02 2011
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
On Fri, 02 Dec 2011 13:25:02 +0100
Timon Gehr <timon.gehr gmx.ch> wrote:


 Its design is not broken and the implementation has almost caught up. 
 (there are some obscure implicit conversions that should be allowed
 and some that shouldn't that DMD does not get right yet.) Please give 
 objective information (as Jesse Phillips did.)


There isn't a need to be objective. Opinion does give insight into
things and at times is obviously an opinion. And in fact this is a good
example of what a meant by "going in blind." There is not implementation
of D that is complete and trying to use every feature will get you in
cold water.

Const is like no other in D, and while it recently got major usability
improvements it does have its issues. But not using const is possible
in D and is also easy to get around cast().
Dec 02 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/02/2011 05:57 PM, Jesse Phillips wrote:

 On Fri, 02 Dec 2011 13:25:02 +0100
 Timon Gehr<timon.gehr gmx.ch>  wrote:


 Its design is not broken and the implementation has almost caught up.
 (there are some obscure implicit conversions that should be allowed
 and some that shouldn't that DMD does not get right yet.) Please give
 objective information (as Jesse Phillips did.)


 There isn't a need to be objective. Opinion does give insight into
 things and at times is obviously an opinion. And in fact this is a good
 example of what a meant by "going in blind." There is not implementation
 of D that is complete and trying to use every feature will get you in
 cold water.


Oh it is certainly good to have and communicate opinions. It is just 
that they should be clearly marked as such. I won't even attempt to 
argue that his point of view is not important.


 Const is like no other in D, and while it recently got major usability
 improvements it does have its issues. But not using const is possible
 in D and is also easy to get around cast().


It is important to make a cut between what is not supposed to work and 
what is not yet implemented properly. He said 'the _language_ suffers 
from const issues'. And 'its part-broken'. The design is fundamentally 
sound. It could maybe be extended to cover more use cases, but the 
issues with const he addresses have been resolved with inout, and it is 
likely that the implementation will soon be correct.

Also he probably is doing some considerably different stuff than, for 
example, I am, because I don't run into that kind of 
productivity-blocker issues.
Dec 02 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/2/2011 10:46 AM, Timon Gehr wrote:

 Oh it is certainly good to have and communicate opinions. It is just 
 that they should be clearly marked as such.


I like how you're leading by example, it makes it so much easier to 
learn The Right Thing (tm) from you.


 I won't even attempt to argue that his point of view is not important.


This sentence is a lie?


 It is important to make a cut between what is not supposed to work and 
 what is not yet implemented properly. He said 'the _language_ suffers 
 from const issues'. And 'its part-broken'. The design is fundamentally 
 sound. It could maybe be extended to cover more use cases, but the 
 issues with const he addresses have been resolved with inout, and it 
 is likely that the implementation will soon be correct.


"The design is fundamentally sound." --> No offense, but maybe it's 
_you_ who should follow your advice and actually provide some support? 
At least I'm giving you examples; you're not giving me anything.
Oh, sorry, I forgot that your arguments are all objective and correct by 
definition. I didn't notice that you didn't mark them as subjective.


 Also he probably is doing some considerably different stuff than, for 
 example, I am, because I don't run into that kind of 
 productivity-blocker issues.


And that makes my point of view unimportant. Yes, that's a completely 
objective and unbiased point of view, it makes perfect sense.

Sorry for forcing you to read my unimportant feedback.
Dec 02 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/02/2011 09:50 PM, Mehrdad wrote:

 On 12/2/2011 10:46 AM, Timon Gehr wrote:

 Oh it is certainly good to have and communicate opinions. It is just
 that they should be clearly marked as such.


 I like how you're leading by example, it makes it so much easier to
 learn The Right Thing (tm) from you.


 I won't even attempt to argue that his point of view is not important.


 This sentence is a lie?


No.


 It is important to make a cut between what is not supposed to work and
 what is not yet implemented properly. He said 'the _language_ suffers
 from const issues'. And 'its part-broken'. The design is fundamentally
 sound. It could maybe be extended to cover more use cases, but the
 issues with const he addresses have been resolved with inout, and it
 is likely that the implementation will soon be correct.


 "The design is fundamentally sound." --> No offense, but maybe it's
 _you_ who should follow your advice and actually provide some support?


Sound basically means that it is not broken. Broken means that the type 
system is inconsistent. It is not. (while DMD does not implement a 
consistent const system because of array-covariance related bugs.)



 At least I'm giving you examples; you're not giving me anything.


I am resolving/relegating to the compiler implementation the issues you 
run into. You have yet to point out a problem with the design.


 Oh, sorry, I forgot that your arguments are all objective and correct by
 definition. I didn't notice that you didn't mark them as subjective.


 Also he probably is doing some considerably different stuff than, for
 example, I am, because I don't run into that kind of
 productivity-blocker issues.


 And that makes my point of view unimportant.


Well, as I already pointed out before you wrote that: this is not my 
point of view. Are you reflecting? I do not understand how my post can 
possibly be interpreted that way, but communicating over the internet 
has some drawbacks.

Again: How can the fact that you apparently do different things than I 
do make your point of view unimportant? I would say, on the contrary?


 Yes, that's a completely objective and unbiased point of view, it makes
perfect sense.


This sentence is a lie?


 Sorry for forcing you to read my unimportant feedback.


No reason to get offended. I am sorry if you were.
Dec 02 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Dec 2011 02:25:26 -0500, Mehrdad <wfunction hotmail.com> wrote:


 On 12/1/2011 1:24 PM, Buk wrote:

 Is D ready for prime time?


 Idk, the fact that I run across transitive-const-related situations like
 stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d  
 <http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d>
 makes it so I can't use D at all, since it's hard to go around these  
 issues sometimes.


What you are missing is one of the same things I need for dcollections --  
tail const for structs.

Essentially, the problem boils down to, I want to be able to have  
const(Slice!T) turn implicitly into Slice!const(T).  Slice!const(T) is  
more usable because only the data pointed at is const, the internal pieces  
of the slice are not.

But to solve your original problem, this seems to work on 2.056, but is  
weird:

import std.stdio;

struct S
{
     int x;
     inout this(inout int t)
     {
         this.x = t;
     }
}

void main()
{
     int i = 1;
     immutable int i2 = 1;
     const int i3 = 1;

     auto s = S(i);
     auto s2 = S(i2);
     auto s3 = S(i3);
     auto s4 = const(S)(1);
     writefln("s: %s, s2: %s, s3: %s, s4: %s", typeof(s).stringof,  
typeof(s2).stringof, typeof(s3).stringof, typeof(s4).stringof);
}

outputs:
s: S, s2: immutable(S), s3: const(S), s4: S

The s4 is the weird part, I clearly asked for a const(S), and it gave me  
an S due to the inout parameter being mutable.  I might file a bug on  
this, but to be honest, I never envisioned how inout would work on a  
ctor.  The s, s2, and s3 parts are pretty cool though :)


 As long as the language suffers from const issues, I think, it won't be  
 ready for prime time, since 'const' is supposed to be one of its highest  
 strengths, and at the same time it's part-broken.


inout has fixed many of these issues.  There is still work to be done, but  
I think we're in a much better place than we were before.

-Steve
Dec 02 2011
prev sibling parent Kagamin <spam here.lot> writes:
Mehrdad Wrote:


 On 12/1/2011 1:24 PM, Buk wrote:

 Is D ready for prime time?


 Idk, the fact that I run across transitive-const-related situations like
 stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d 
 <http://stackoverflow.com/questions/7948612/annoying-transitive-const-ness-issue-in-d>
 makes it so I can't use D at all, since it's hard to go around these 
 issues sometimes.


I think, the correct diagnostic it your case should be "const constructor is
not defined". Also const system gives you a chance to design const-correct
code, it doesn't necessarily make it simple. Design takes a lot of effort. That
said, yes, you can get stuck unable to solve your problem with your skills.
Though I don't think const-correct code is a must: I didn't see a single bug
caused by lack of const. Const-correct code doesn't buy you a lot, really.

btw, the inout solution is not quite right thing there, Steven proposed the
correct design: const opSlice should return Slice!const(T), not const(Slice!T).
Dec 04 2011
prev sibling next sibling parent torhu <no spam.invalid> writes:
On 01.12.2011 22:24, Buk wrote:

 Simple question, though not necessarily a simple answer:

 Is D ready for prime time?

 Sub-questions:

 1. How stable is the language specification?
 2. How stable is the language implementation?
 3. How stable are the standard library specifications?
 4. How stable are the standard library implantations?

 The last time I looked was just after the D1/D2 split, and much of the design
 was being revamped and the rate of changes and deprecations was (IMO) too high
 to consider its use for complex, multi-developer projects.

 Looking around the docs here, I see that some of the libraries are due for
 deprecation early next year. Barring surprises, are they likely to be the last
 major changes?

 Thanks for your time, buk.


If you want something that's ready for prime time, D1+Tango is what I 
would recommend.  I think D2 is not there yet.  The language has gotten 
a lot more complex, and as a result of that, they are not quite done 
figuring out how to get all of it to fit together yet.  A least that's 
my impression. I've used D and followed this newsgroup since 2006, so I 
don't think I'm completely clueless.

Some of the new features are not yet implemented, which others have 
mentioned.

As for Phobos 2, I don't know what to think yet.  I find it hard to 
trust that the template-heavy code is fast, that the compiler can 
reliably optimize all those layers away.
Dec 02 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
On 01.12.2011 22:24, Buk wrote:

 Simple question, though not necessarily a simple answer:

 Is D ready for prime time?

 Sub-questions:

 1. How stable is the language specification?
 2. How stable is the language implementation?


I made a list of major language issues in mid-2009.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#section6

The next release (2.057, release in December) implements half of the 
remaining items.


 3. How stable are the standard library specifications?
 4. How stable are the standard library implantations?

 The last time I looked was just after the D1/D2 split, and much of the design
 was being revamped and the rate of changes and deprecations was (IMO) too high
 to consider its use for complex, multi-developer projects.

 Looking around the docs here, I see that some of the libraries are due for
 deprecation early next year. Barring surprises, are they likely to be the last
 major changes?

 Thanks for your time, buk.
Dec 03 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Interesting to see "Inheriting constructors" there under pending decision.
Dec 03 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Removing new was proposed? I don't think I want to know, but I'm curious.
Dec 03 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/03/2011 03:57 PM, Don wrote:

 On 01.12.2011 22:24, Buk wrote:

 Simple question, though not necessarily a simple answer:

 Is D ready for prime time?

 Sub-questions:

 1. How stable is the language specification?
 2. How stable is the language implementation?


 I made a list of major language issues in mid-2009.

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#section6

 The next release (2.057, release in December) implements half of the
 remaining items.


 3. How stable are the standard library specifications?
 4. How stable are the standard library implantations?

 The last time I looked was just after the D1/D2 split, and much of the
 design
 was being revamped and the rate of changes and deprecations was (IMO)
 too high
 to consider its use for complex, multi-developer projects.

 Looking around the docs here, I see that some of the libraries are due
 for
 deprecation early next year. Barring surprises, are they likely to be
 the last
 major changes?

 Thanks for your time, buk.




- Clean up is(XXX) and __traits(XXX) syntax (eg via meta.XXX proposal, 
Bugzilla:3702).

There is nothing wrong with is(XXX), so what is this about?
Dec 03 2011
parent reply David Nadlinger <see klickverbot.at> writes:
Famous last words:

On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


David
Dec 03 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/04/2011 12:09 AM, David Nadlinger wrote:

 Famous last words:

 On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


 David


An explanation would be more helpful.
Dec 03 2011
parent reply Don <nospam nospam.com> writes:
On 04.12.2011 00:13, Timon Gehr wrote:

 On 12/04/2011 12:09 AM, David Nadlinger wrote:

 Famous last words:

 On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


 David


 An explanation would be more helpful.


For many years is(xxx) been reviled as the ugliest thing in the 
language. The simple forms are OK, but features kept getting piled onto 
it until it became clearly unworkable.

And there are stupidities like:

alias void delegate () dg;
alias void function () fn;
static assert(is (dg == delegate));  // true
static assert(is (fn == function));  // fails!
Dec 03 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/04/2011 03:10 AM, Don wrote:

 On 04.12.2011 00:13, Timon Gehr wrote:

 On 12/04/2011 12:09 AM, David Nadlinger wrote:

 Famous last words:

 On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


 David


 An explanation would be more helpful.


 For many years is(xxx) been reviled as the ugliest thing in the
 language. The simple forms are OK, but features kept getting piled onto
 it until it became clearly unworkable.


So why not keep the simple forms and just replace the more obscure 
functionality that is better expressed by other means?

Removing is expressions entirely would break most D code (at least it 
would break all of mine).


 And there are stupidities like:

 alias void delegate () dg;
 alias void function () fn;
 static assert(is (dg == delegate)); // true
 static assert(is (fn == function)); // fails!


I'd like to just see that fixed, but then old code would be silently 
miscompiled...
Dec 03 2011
parent reply Don <nospam nospam.com> writes:
On 04.12.2011 03:40, Timon Gehr wrote:

 On 12/04/2011 03:10 AM, Don wrote:

 On 04.12.2011 00:13, Timon Gehr wrote:

 On 12/04/2011 12:09 AM, David Nadlinger wrote:

 Famous last words:

 On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


 David


 An explanation would be more helpful.


 For many years is(xxx) been reviled as the ugliest thing in the
 language. The simple forms are OK, but features kept getting piled onto
 it until it became clearly unworkable.


 So why not keep the simple forms and just replace the more obscure
 functionality that is better expressed by other means?


Yeah, that's the idea.


 Removing is expressions entirely would break most D code (at least it
 would break all of mine).


Yes. Nobody's ever proposed complete removal of is expressions.
It's the things like:
is (foo bar == super)
which I think you can't understand without looking up the spec every 
time. We still don't have a nice way of expressing such things.


 And there are stupidities like:

 alias void delegate () dg;
 alias void function () fn;
 static assert(is (dg == delegate)); // true
 static assert(is (fn == function)); // fails!


 I'd like to just see that fixed, but then old code would be silently
 miscompiled...
Dec 03 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/04/2011 03:53 AM, Don wrote:

 On 04.12.2011 03:40, Timon Gehr wrote:

 On 12/04/2011 03:10 AM, Don wrote:

 On 04.12.2011 00:13, Timon Gehr wrote:

 On 12/04/2011 12:09 AM, David Nadlinger wrote:

 Famous last words:

 On 12/3/11 11:47 PM, Timon Gehr wrote:

 There is nothing wrong with is(XXX), […]


 David


 An explanation would be more helpful.


 For many years is(xxx) been reviled as the ugliest thing in the
 language. The simple forms are OK, but features kept getting piled onto
 it until it became clearly unworkable.


 So why not keep the simple forms and just replace the more obscure
 functionality that is better expressed by other means?


 Yeah, that's the idea.


 Removing is expressions entirely would break most D code (at least it
 would break all of mine).


 Yes. Nobody's ever proposed complete removal of is expressions.
 It's the things like:
 is (foo bar == super)
 which I think you can't understand without looking up the spec every
 time. We still don't have a nice way of expressing such things.


Ok, thanks. I fully agree that those should be replaced.
Dec 03 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2011 6:53 PM, Don wrote:

 It's the things like:
 is (foo bar == super)
 which I think you can't understand without looking up the spec every time. We
 still don't have a nice way of expressing such things.


I agree, but that's a low priority for now, because at least you can get work 
done with it.
Dec 04 2011
parent reply Don <nospam nospam.com> writes:
On 05.12.2011 06:27, Walter Bright wrote:

 On 12/3/2011 6:53 PM, Don wrote:

 It's the things like:
 is (foo bar == super)
 which I think you can't understand without looking up the spec every
 time. We
 still don't have a nice way of expressing such things.


 I agree, but that's a low priority for now, because at least you can get
 work done with it.


Right. But it's hard to come up with high-priority language issues these 
days. The old ones have been fixed. <g>.
Dec 05 2011
parent Manu <turkeyman gmail.com> writes:
On 5 December 2011 15:33, Don <nospam nospam.com> wrote:


 On 05.12.2011 06:27, Walter Bright wrote:


 On 12/3/2011 6:53 PM, Don wrote:


 It's the things like:
 is (foo bar == super)
 which I think you can't understand without looking up the spec every
 time. We
 still don't have a nice way of expressing such things.


 I agree, but that's a low priority for now, because at least you can get
 work done with it.


 Right. But it's hard to come up with high-priority language issues these
 days. The old ones have been fixed. <g>.


I've got one... there's no 128bit hardware vector type! ;) .. That's pretty
high for me :P
Even if it doesn't do anything, just allocates and addresses the hardware
regs and schedules loads/stores... Can write maths in asm, but need a type
to pass to/from functions and store in structs/classes...
Dec 05 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


Right. But it's hard to come up with high-priority language issues these days.
The old ones have been fixed. <g>.<


There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:

x = x++;

Or code like (bar and baz are not pure):

int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
    int w = foo(bar(5), baz(3));
    return w;
}

See also:
http://en.wikipedia.org/wiki/Sequence_point

You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.

A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).

Bye,
bearophile
Dec 06 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/06/2011 09:37 AM, bearophile wrote:

 Don:


 Right. But it's hard to come up with high-priority language issues these days.
The old ones have been fixed.<g>.<


 There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:

 x = x++;

 Or code like (bar and baz are not pure):

 int z = 0;
 int foo(int x, int y) { return x + y; }
 int bar(int x) { z++; return x * x + z; }
 int baz(int x) { z--; return 2 * x + z; }
 int main() {
      int w = foo(bar(5), baz(3));
      return w;
 }

 See also:
 http://en.wikipedia.org/wiki/Sequence_point


I think ',' in parameter lists are already sequence points.


 You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.

 A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).

 Bye,
 bearophile
Dec 06 2011
parent reply "Kagamin" <spam here.lot> writes:
 int z = 0;
 int foo(int x, int y) { return x + y; }
 int bar(int x) { z++; return x * x + z; }
 int baz(int x) { z--; return 2 * x + z; }
 int main() {
      int w = foo(bar(5), baz(3));
      return w;
 }
 See also:
 http://en.wikipedia.org/wiki/Sequence_point


 I think ',' in parameter lists are already sequence points.


They aren't, but a function call is a sequence point, so bar is guaranteed to
be called before baz.
Dec 06 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/07/2011 08:35 AM, Kagamin wrote:

 int z = 0;
 int foo(int x, int y) { return x + y; }
 int bar(int x) { z++; return x * x + z; }
 int baz(int x) { z--; return 2 * x + z; }
 int main() {
 int w = foo(bar(5), baz(3));
 return w;
 }
 See also:
 http://en.wikipedia.org/wiki/Sequence_point


 I think ',' in parameter lists are already sequence points.


 They aren't, but a function call is a sequence point, so bar is
 guaranteed to be called before baz.


?

If bar is guaranteed to be called before baz, then the ',' is associated 
with a sequence point. You are right that there is a sequence point 
before a function call, but that only guarantees that bar and baz are 
called before foo, and says nothing about the evaluation order of bar 
and baz (note that function calls are sequence points in C/C++, but the 
order of argument evaluation is unspecified).
Dec 07 2011
parent "Kagamin" <spam here.lot> writes:
 http://en.wikipedia.org/wiki/Sequence_point


 I think ',' in parameter lists are already sequence points.


 They aren't, but a function call is a sequence point, so bar is
 guaranteed to be called before baz.


 ?
 If bar is guaranteed to be called before baz, then the ',' is associated with
a sequence point. You are right that there is a sequence point before a
function call, but that only guarantees that bar and baz are called before foo,
and says nothing about the evaluation order of bar and baz (note that function
calls are sequence points in C/C++, but the order of argument evaluation is
unspecified).


Well, if sequence points don't go in a sequence, that would mean a total mess.
Order of argument evaluation is usually unspecified because arguments are
usually simple values and thus don't contain sequence points.
Dec 07 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 06.12.2011 09:37, bearophile wrote:

 Don:


 Right. But it's hard to come up with high-priority language issues these days.
The old ones have been fixed.<g>.<


 There are several things that I'd like to see fixed/improved in D still.


Yes, of course. But most of the showstoppers are done.
Not so long ago there were major features in the spec or in TDPL that 
weren't implemented at all - contracts,  safe, pure, inout, TDPL 
operator overloading, almost nothing worked in CTFE, Phobos didn't 
compile on 64 bits, ...
Dec 07 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 07, 2011 09:16:48 Don wrote:

 On 06.12.2011 09:37, bearophile wrote:

 Don:

 Right. But it's hard to come up with high-priority language issues
 these days. The old ones have been fixed.<g>.<> 


 There are several things that I'd like to see fixed/improved in D still.


 
 Yes, of course. But most of the showstoppers are done.
 Not so long ago there were major features in the spec or in TDPL that
 weren't implemented at all - contracts,  safe, pure, inout, TDPL
 operator overloading, almost nothing worked in CTFE, Phobos didn't
 compile on 64 bits, ...


Where does the compiler stand with multiple alias thises (as TDPL describes). 
AFAIK, it still doesn't support them at all. That would be a major feature 
from TDPL which hasn't be implemented. But yes, a lot of work has been done, 
and we're much closer to having everything fully implemented.

- Jonathan M Davis
Dec 07 2011
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 07-12-2011 09:16, Don wrote:

 On 06.12.2011 09:37, bearophile wrote:

 Don:


 Right. But it's hard to come up with high-priority language issues
 these days. The old ones have been fixed.<g>.<


 There are several things that I'd like to see fixed/improved in D still.


 Yes, of course. But most of the showstoppers are done.
 Not so long ago there were major features in the spec or in TDPL that
 weren't implemented at all - contracts,  safe, pure, inout, TDPL
 operator overloading, almost nothing worked in CTFE, Phobos didn't
 compile on 64 bits, ...


Speaking of contracts, what are the plans for:

* Supporting contracts in interfaces - sometimes the compiler will not 
allow this, claiming that a method body must be present (other times it 
Just Works)
* this pointer adjustment in interface contracts - using other interface 
members in an interface contract currently crashes because the this 
pointer isn't adjusted correctly
* Supporting pre-state (AKA 'old')
* Supporting contracts specific to exceptional function exit

? These are all rather essential to have usable contract programming, 
probably most significantly the interface ones.

- Alex
Dec 07 2011