www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Stable D version?

reply "Tourist" <gravatar gravatar.com> writes:
Hi guys,

I've been following the forums for a while. I'm interested in 
looking into D, but I understand that currently it changes often, 
and is not very reliable.
I've also read that there's a new release model planned, where a 
stable version of the language is released every year or two. Is 
that so? When would it take place?

What's holding you from releasing a version now and declaring it 
stable for e.g. a year?
Apr 21 2013
next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 Hi guys,

 I've been following the forums for a while. I'm interested in 
 looking into D, but I understand that currently it changes 
 often, and is not very reliable.
 I've also read that there's a new release model planned, where 
 a stable version of the language is released every year or two. 
 Is that so? When would it take place?

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

The year long support is not going to be put in place at this time. Several took issue with that plan considering it to provide limited/no benefit. The core dev team is currently getting use to using a staging branch to prepare a release. Eventually we may see a release get patched up until the point of the next release, but this has not yet been adopted by the core team or those writing patches. Having a clear understanding of what goes where has been a big point of discussion which again no one could agree on the specifics.
Apr 21 2013
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question. David
Apr 22 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/13 4:33 AM, eles wrote:
 On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable version that
 is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?

I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version. During the meantime, users could live with workarounds and "forbidden to do that!". Look at C and MISRA-C. It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools. A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions. C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers. Being predictable does matter sometimes. Tools matter too.

I think we shouldn't follow the C++ model. Whatever made C++ successful is not what'll make D successful. The context and expectations are very different now. Andrei
Apr 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote:
 I think we shouldn't follow the C++ model. Whatever made C++
 successful is not what'll make D successful. The context and
 expectations are very different now.

 Andrei

That's a pretty vague assertion. Please define the model that you have in mind for D. OK. Don't follow the C++ model. But, then, what is the model that D follows? Is there any such model?

I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei
Apr 23 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/23/2013 10:21 PM, eles wrote:
 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
 On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu

having initially an incomplete specification. Nowadays the expectations are much higher. Andrei

As long as you keep changing the language, no specification will ever be complete.

It is the other way round. As long as there is no specification, there are no language changes, as everything can be cast as a bug fix towards implementing some imaginary specification that is different for each dev.
 C++ will long advance. D must be out and living before C++14. Then, it
 will be too late.

I think there is no reason to assume that C++ can be fixed.
 My view.

Obviously.
Apr 23 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 23.04.2013 22:21, schrieb eles:
 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:
 On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu

having initially an incomplete specification. Nowadays the expectations are much higher. Andrei

As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.

C++ was created around 1985, that is 28 years as of today. I remember going through the ARM (Annotated Reference Manual) around 1995 and not finding a C++ compiler that was able to compile all examples. Following "The C Users Journal", shortly thereafter renamed "The C/C++ Users Journal" and "C++ Report" and seeing the language change each month, with each C++ compiler offering a different view what the language meant. C++ will be with us for many years to come, but you should not forget that it has a few years in the industry already, and as I mentioned in a separate post, systems programming languages require support from OS vendors. As a supporter for stronger typed languages I look forward not only D, but Rust and Go as well, even with its issues, to gain wider support, but it takes time. -- Paulo
Apr 23 2013
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.04.2013 12:03, schrieb Dicebot:
 On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
 I also think when modules are integrated into the C++ standard, for
 most developers, there won't be any case left for D. Even though D
 technically is superior in almost every way, conservatism is strong
 enough.

C++ will never be sufficiently changed to leave no chance for other native languages. It is doomed because of mandatory backwards compatibility with huge legacy package. Main issues of C++ are not lack of advanced features but inconvenient design of basic features. Well, D is trying to have its own share of those issues too :P

True, but only now the major OS vendors are switching from C to C++ as their main systems programming language. How long will take until they replace it with something else? -- Paulo
Apr 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-29 01:11, Mehrdad wrote:

 Curious, which ones are you referring to?

 Windows uses C for the kernel, for many reasons, one of which is that C
 (unlike C++) discourages storing large objects on the stack.

 Linux uses C for the kernel too, mainly because Walter hates C++ (and
 C++ programmers).

 Which vendors have switched to C++ for systems programming?

The kernel in Mac OS X is written in a subset of C++. -- /Jacob Carlborg
Apr 28 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question.

That would not be a benefit, maybe. But, however, an answer to the question: "will EVER D be finished?" would be more than wonderful. Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.) Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done. D starts looking like the D in _D_uke Nukem Forever (and forever it will take...). I got old looking at D and hoping that it will ever get released. Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good. Will D remain the forever unborn child of the programming languages? Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation. At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc. I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?... Radons&Minayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained.
Apr 22 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
I started a project a month ago, and for the moment my feeling is 
just: D can already be used as it. It's not "finished" but the 
state is stable enough I think.

The compiler is not perfect (not always really explicit messages, 
not able to compile for all architecture like ARM,...), but a lot 
of things can already be done.

I made few games on Nintendo DS console, with a pretty old gcc 
version on which it wasn't recommended to develop in C++ due to 
the lack of support of some core feature of language. Now I can 
just find D more advanced.

C++11 and C++14 aren't really interesting for me, just cause of 
lack of support of some compilers like Visual Studio, it really 
can be the hell to realize portable applications (iOS, Android, 
Windows, Mac OS X, gcc, clang, cl,...). Without talking of 
template meta programming that are pretty hard to compile on 
different compilers.
Because D is pretty well specified, you will never loose your 
time with compilers flags, missing features on a platform or 
macro issues before an include,...

I was surprise how it's easy to progress in D just because it's 
fast to build and test. There is also a lot of advanced features 
like __traits,... that are directly in the core of language/std 
lib.

Any IDE support D perfectly but Visual D and MonoD are just good 
enough for starting.
Apr 22 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

The problem is not that D is usable or not as it is. The problem 
is that, until officially "handled to the user", it won't be 
taken too serious by the industry.

In other words, you won't find jobs as a D programmer.

C++ will improve more with the pending modules and other features 
that do not even have to wait 2014 for that (a TR will do the 
job). But the point here is not about C++.

The problem with D is that it's never finished. Everybody waits 
for the next version. Everytime I spoke to my boss about D, the 
answer was like: "hmmm... we'll discuss about it when it's ready".

D1 was killed by a under-developed phobos and by the the conflict 
tango-phobos, at least in part. What really killed D1 was the 
announcement of D2. And I have the feeling that after D2 is 
rolled out, people will start working on D3.

That's the wrong approach. If it is usable as it is, then shift 
the main effort on tools for it and on promoting it. Then, let it 
in the market, get feedback from compiler implementors and 
commercial users and formalize that as a proposal for the next D 
standard. Then, after public scrutinize the proposed changes for 
6 months or 1 tear, implement them.

Only recently the focus was placed on implementing those shared 
libraries. Really, who'd have been expected to use D in 
commercial, large applications, without that support? Why did 
people wait for so long?

Keep running circles around Optlink and other specific tools just 
for the sake of them? I agree they *were* valuable, but they 
*were*. Focus on the ldc or gcc/gdc implementation, for example. 
Use that as the official compiler. Do not split effort. There are 
a lot of standard tools that will facilitate adoption, yet the 
effort is misplaced.

Put the current language version on the market, along with a 
document summarizing proposals for the future standard and get 
feedback from users that will start using it for real 
applications, on large scale.

No need, for now, to make Phobos the best of the best. The curse 
of Tango vanished. Ship it as it is, incomplete but cleaned, then 
some libraries will be written and they will find almost 
naturally place in the standard library, just as the C++ standard 
integrates parts from Boost, integrated STL etc.

Pursuing perfection will miss the good.
Apr 22 2013
prev sibling next sibling parent "Tourist" <gravatar gravatar.com> writes:
On Tuesday, 23 April 2013 at 01:06:49 UTC, eles wrote:
 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

 The problem is not that D is usable or not as it is. The 
 problem is that, until officially "handled to the user", it 
 won't be taken too serious by the industry.

 In other words, you won't find jobs as a D programmer.

 C++ will improve more with the pending modules and other 
 features that do not even have to wait 2014 for that (a TR will 
 do the job). But the point here is not about C++.

 The problem with D is that it's never finished. Everybody waits 
 for the next version. Everytime I spoke to my boss about D, the 
 answer was like: "hmmm... we'll discuss about it when it's 
 ready".

 D1 was killed by a under-developed phobos and by the the 
 conflict tango-phobos, at least in part. What really killed D1 
 was the announcement of D2. And I have the feeling that after 
 D2 is rolled out, people will start working on D3.

 That's the wrong approach. If it is usable as it is, then shift 
 the main effort on tools for it and on promoting it. Then, let 
 it in the market, get feedback from compiler implementors and 
 commercial users and formalize that as a proposal for the next 
 D standard. Then, after public scrutinize the proposed changes 
 for 6 months or 1 tear, implement them.

 Only recently the focus was placed on implementing those shared 
 libraries. Really, who'd have been expected to use D in 
 commercial, large applications, without that support? Why did 
 people wait for so long?

 Keep running circles around Optlink and other specific tools 
 just for the sake of them? I agree they *were* valuable, but 
 they *were*. Focus on the ldc or gcc/gdc implementation, for 
 example. Use that as the official compiler. Do not split 
 effort. There are a lot of standard tools that will facilitate 
 adoption, yet the effort is misplaced.

 Put the current language version on the market, along with a 
 document summarizing proposals for the future standard and get 
 feedback from users that will start using it for real 
 applications, on large scale.

 No need, for now, to make Phobos the best of the best. The 
 curse of Tango vanished. Ship it as it is, incomplete but 
 cleaned, then some libraries will be written and they will find 
 almost naturally place in the standard library, just as the C++ 
 standard integrates parts from Boost, integrated STL etc.

 Pursuing perfection will miss the good.

I couldn't have said it better!
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:
 I started a project a month ago, and for the moment my feeling 
 is just:
 D can already be used as it.

Input: import std.stdio; struct S { string a; } pragma(msg, S("x") == S("x".idup)); void main() { writeln(S("x") == S("x".idup)); } Output: true false ... Nope, still broken.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
 ...


 Nope, still broken.

The behavior isn't too surprising to me. Your code is buggy. Defining opEquals gets you the behavior you might want: import std.stdio, std.algorithm; struct S { string a; bool opEquals(S rhs) { return a.equal(rhs.a); } } pragma(msg, S("x") == S("x".idup)); void main() { writeln(S("x") == S("x".idup)); } outputs: true true
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
 ...


 Nope, still broken.

The behavior isn't too surprising to me. Your code is buggy.

?!??!
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
 ?!??!

I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check. "x" and "x".idup are two different things. "x" might be: ptr = 0xDEADBEEF length = 1 and "x".idup might be: ptr = 0xDEADBEEE length = 1 Clearly they are not equal. If you have a particular definition that isn't the same as the the bit-level basic equality, you have a method of defining it. For why the compiler treats them the same... well, it simply doesn't create a new place for "x".idup. Simple optimization that doesn't matter unless you're comparing their identity.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
 ?!??!

I'm confused by why you might be confused by this. opEquals by default is simply a bit-level value check.

Yeah, hence it's broken.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
 Yeah, hence it's broken.

Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you?
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:
 ?!??!

opEquals by default is simply a bit-level value check.

In fact, it's _doubly_ broken... import std.stdio; struct S { float d; } void main() { writeln(+0.0); writeln(-0.0); writeln(S(+0.0) == S(-0.0)); } Output: 0 -0 true
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:37:12 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:
 Yeah, hence it's broken.

Um... I don't see the problem. Do you expect the compiler to treat strings/arrays special and look up the equal method in the standard library? Wouldn't that confuse you when it doesn't apply to your structures? Furthermore, requiring the compiler to know about the standard library doesn't sound broken to you?

It has nothing to do with the standard library. It should do whatever operator == does.
Apr 22 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--bcaec53f346da9b6b104daffd74b
Content-Type: text/plain; charset=UTF-8

2013/4/23 Mehrdad <wfunction hotmail.com>

 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

 I started a project a month ago, and for the moment my feeling is just:
 D can already be used as it.

Input: import std.stdio; struct S { string a; } pragma(msg, S("x") == S("x".idup)); void main() { writeln(S("x") == S("x".idup)); } Output: true false Nope, still broken.

This is mostly expected behavior. During compilation value identities are not guaranteed. Because compile time evaluation is always done after constant folding, and constant folding would fold "x".idup to "x", then S("x") == S("x") is evaluated to true. Kenji Hara --bcaec53f346da9b6b104daffd74b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
2013/4/23 Mehrdad <span dir=3D"ltr">&lt;<a href=3D"mailto:wfunction hotmai=

e class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bot= tom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:= <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin-t= op:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-wid= th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= eft:1ex"> I started a project a month ago, and for the moment my feeling is just:<br> D can already be used as it.<br> </blockquote> <br></div> Input:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 import std.stdio;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct S { string a; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 pragma(msg, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = S(&quot;x&quot;) =3D=3D S(&quot;x&quot;.idup));<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 void main() { writeln(S(&quot;x&quot;) =3D=3D S= (&quot;x&quot;.idup)); }<br> <br> Output:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 true<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 false<br><br> Nope, still broken.<br> </blockquote></div><br></div></div><div class=3D"gmail_extra">This is mostl= y expected behavior. During compilation value=C2=A0identities are not guara= nteed.</div><div class=3D"gmail_extra">Because compile time evaluation is a= lways done after constant folding, and constant folding would fold &quot;x&= quot;.idup to &quot;x&quot;, then=C2=A0S(&quot;x&quot;) =3D=3D S(&quot;x&qu= ot;)=C2=A0is evaluated to true.<br class=3D""> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Kenji= Hara</div></div> --bcaec53f346da9b6b104daffd74b--
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:
 2013/4/23 Mehrdad <wfunction hotmail.com>

 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

 I started a project a month ago, and for the moment my 
 feeling is just:
 D can already be used as it.

Input: import std.stdio; struct S { string a; } pragma(msg, S("x") == S("x".idup)); void main() { writeln(S("x") == S("x".idup)); } Output: true false Nope, still broken.

This is mostly expected behavior. During compilation value identities are not guaranteed. Because compile time evaluation is always done after constant folding, and constant folding would fold "x".idup to "x", then S("x") == S("x") is evaluated to true. Kenji Hara

I'm not saying the 'true' is broken, I'm saying the 'false' is broken. And don't miss this one, which contradicts the behavior above http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:
 It has nothing to do with the standard library.
 It should do whatever operator == does.

Sounds slow. We really need a way for you to choose to have it your way and the way it is now. Oh, there's opEquals. Now we can both be happy. :)
Apr 22 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043894c5256e1604daffedb7
Content-Type: text/plain; charset=UTF-8

In floating point value comparison, +0.0 is equal to -0.0.

    auto x = +0.0;
    auto y = -0.0;
    assert(x == y);

Kenji Hara


2013/4/23 Mehrdad <wfunction hotmail.com>

 On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:

 ?!??!

opEquals by default is simply a bit-level value check.

In fact, it's _doubly_ broken... import std.stdio; struct S { float d; } void main() { writeln(+0.0); writeln(-0.0); writeln(S(+0.0) == S(-0.0)); } Output: 0 -0 true

--f46d043894c5256e1604daffedb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">In floating point value comparison, +0.0 is equal to -0.0.= <div><div><br></div><div>=C2=A0 =C2=A0=C2=A0auto x =3D +0.0;</div><div>=C2= =A0 =C2=A0=C2=A0auto y =3D -0.0;</div><div>=C2=A0 =C2=A0 assert(x =3D=3D y)= ;</div></div><div><br></div><div>Kenji Hara</div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/4/= 23 Mehrdad <span dir=3D"ltr">&lt;<a href=3D"mailto:wfunction hotmail.com" t= arget=3D"_blank">wfunction hotmail.com</a>&gt;</span><br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"im">On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wro= te:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> ?!??!<br> </blockquote> <br></div><div class=3D"im"> opEquals by default is simply a bit-level value check.<br> </div></blockquote> <br> <br> <br> In fact, it&#39;s _doubly_ broken...<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 import std.stdio;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct S { float d; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 void main()<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 writeln(+0.0);<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 writeln(-0.0);<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 writeln(S(+0.0) =3D=3D S(-0.0));<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br> <br> <br> Output:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -0<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 true<br> </blockquote></div><br></div> --f46d043894c5256e1604daffedb7--
Apr 22 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043894c5a45bb804db0000c1
Content-Type: text/plain; charset=UTF-8

2013/4/23 Mehrdad <wfunction hotmail.com>

 On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:

 This is mostly expected behavior. During compilation value identities are
 not guaranteed.
 Because compile time evaluation is always done after constant folding, and
 constant folding would fold "x".idup to "x", then S("x") == S("x") is

 evaluated to true.

 Kenji Hara

I'm not saying the 'true' is broken, I'm saying the 'false' is broken. And don't miss this one, which contradicts the behavior above http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes forum.** dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org<http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org>

Ah, OK. Surely that is a compiler bug which still not fixed. Kenji Hara --f46d043894c5a45bb804db0000c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /4/23 Mehrdad <span dir=3D"ltr">&lt;<a href=3D"mailto:wfunction hotmail.com= " target=3D"_blank">wfunction hotmail.com</a>&gt;</span><br><blockquote cla= ss=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0= px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20= 4);border-left-style:solid;padding-left:1ex"> On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D"i= m"> <br> This is mostly expected behavior. During compilation value identities are<b= r> not guaranteed.<br> Because compile time evaluation is always done after constant folding, and<= br></div> constant folding would fold &quot;x&quot;.idup to &quot;x&quot;, then S(&qu= ot;x&quot;) =3D=3D S(&quot;x&quot;) is<div class=3D"im"><br> evaluated to true.<br> <br> Kenji Hara<br> </div></blockquote> <br> I&#39;m not saying the &#39;true&#39; is broken, I&#39;m saying the &#39;fa= lse&#39; is broken.<br> <br> <br> And don&#39;t miss this one, which contradicts the behavior above<br> <a href=3D"http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.o= rg?page=3D2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org" target=3D"_blank">= http://forum.dlang.org/thread/<u></u>uqkslzjnosrsnyqnhzes forum.<u></u>dlan= g.org?page=3D2#post-<u></u>zdmtaeycpomrhjdeanlw:40forum.<u></u>dlang.org</a=
<br>

</blockquote></div><br></div><div class=3D"gmail_extra">Ah, OK. Surely that= is a compiler bug which still not fixed.</div><div class=3D"gmail_extra"><= br></div><div class=3D"gmail_extra">Kenji Hara</div></div> --f46d043894c5a45bb804db0000c1--
Apr 22 2013
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
On Tuesday, 23 April 2013 at 04:48:05 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:
 It has nothing to do with the standard library.
 It should do whatever operator == does.

Sounds slow. We really need a way for you to choose to have it your way and the way it is now. Oh, there's opEquals. Now we can both be happy. :)

For fast bitwise comparison there's the "is" operator. The "==" operator should be "slow". See also http://d.puremagic.com/issues/show_bug.cgi?id=3789
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:56:13 UTC, kenji hara wrote:
 2013/4/23 Mehrdad <wfunction hotmail.com>

 On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:

 This is mostly expected behavior. During compilation value 
 identities are
 not guaranteed.
 Because compile time evaluation is always done after constant 
 folding, and
 constant folding would fold "x".idup to "x", then S("x") == 
 S("x") is

 evaluated to true.

 Kenji Hara

I'm not saying the 'true' is broken, I'm saying the 'false' is broken. And don't miss this one, which contradicts the behavior above http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes forum.** dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org<http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org>

Ah, OK. Surely that is a compiler bug which still not fixed.

Well, I think the float behavior is correct and the string example is broken, but that wasn't my point anyway. The point was that it's still broken.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
 For fast bitwise comparison there's the "is" operator.
 The "==" operator should be "slow".
 See also http://d.puremagic.com/issues/show_bug.cgi?id=3789

Well okay. The docs will have to be updated for this issue if it's "fixed". For instance: http://dlang.org/ctod.html#structcmp In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to "just work." But I suppose using "is" is more appropriate for this type of behavior. But calling it "broken" is a bit too strong.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
 In any case, I stand by that if you have a particular 
 definition of behavior, you should provide it instead of 
 expecting it to "just work." But I suppose using "is" is more 
 appropriate for this type of behavior. But calling it "broken" 
 is a bit too strong.

Actually, I'm going to strengthen this a bit more. I'd _still_ think it's a good idea to keep structs the way they are. I expect (as I think many would) structs to be very bare metal. Very little auto-magic should touch them because they are used so often for low-level tasks and you really ought to be very precise when you're defining them and their behavior. In that context, "==" being the same as "is" makes sense from my perspective and I wouldn't expect anything else unless I explicitly told it otherwise. If you want some of that type of automatic "just works" behavior, you're probably using structs as more higher level concepts. Maybe consider using a tuple instead? import std.stdio, std.typecons; void main() { writeln(tuple("a") == tuple("a".idup)); } Outputs: true And it's shorter and simpler than the struct example.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
 I suppose using "is" is more appropriate for this type of 
 behavior.

If when you see a == b you think, Hey, that's equivalent to (a.d is b.d) I suppose that when you see (a is b) you think, Hey, that's equivalent to a.d == b.d ?
 But calling it "broken" is a bit too strong.

If it doesn't make sense, it's broken. Implementing == as 'is' by default doesn't make sense when there is already an 'is' operator that could do the same, hence it's broken.
Apr 22 2013
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
On Tuesday, 23 April 2013 at 05:16:35 UTC, Chris Cain wrote:
 Actually, I'm going to strengthen this a bit more. I'd _still_ 
 think it's a good idea to keep structs the way they are. I 
 expect (as I think many would) structs to be very bare metal. 
 Very little auto-magic should touch them because they are used 
 so often for low-level tasks and you really ought to be very 
 precise when you're defining them and their behavior. In that 
 context, "==" being the same as "is" makes sense from my 
 perspective and I wouldn't expect anything else unless I 
 explicitly told it otherwise.

I don't feel strongly about which path is right. But (as Mehrdad has shown) the current behaviour is not consistent either way: strings are compared bitwise, floats are compared logically.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:28:54 UTC, Mehrdad wrote:
 If when you see a == b you think,
 	Hey, that's equivalent to (a.d is b.d)
 I suppose that when you see (a is b) you think,
 	Hey, that's equivalent to a.d == b.d
 ?

Incorrect. When I see a == b, I don't think anything. Thanks to encapsulation, typeof(a) and typeof(b) gets to decide what "==" means. If they happen to be structs, then if the author defined opEquals, then that's what it means. Otherwise, it's just a simple bitwise comparison (or should be).
 If it doesn't make sense, it's broken.


 Implementing == as 'is' by default doesn't make sense when 
 there is already an 'is' operator that could do the same, hence 
 it's broken.

It doesn't make sense to _you_. It's a purely subjective matter. And considering I've explained the way to think about it so it should be cleared up now. It's a minor stumbling block at best. Define opEquals and everything will work how you want. Very simple solution to a problem you seem to be blowing out of proportion. My very first post fixed your bug. Is there something stopping you from defining opEquals for the behavior you want?
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 05:48:08 UTC, Chris Cain wrote:
 Incorrect. When I see a == b, I don't think anything.

I stand corrected I guess. I'll stop thinking as well.
 It doesn't make sense to _you_.

Okay sure, have fun watching people use languages that make more sense to them than D I guess.
 Is there something stopping you from defining opEquals for the 
 behavior you want?

yes, unnecessary waste of time/effort
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
 I stand corrected I guess. I'll stop thinking as well.
 ...
 Okay sure, have fun watching people use languages that make 
 more sense to them than D I guess.

*sigh* I really wish you'd be more cooperative in this conversation. I certainly don't want to drive anyone away from D. I really don't understand why someone would say "If you don't do what I want, I'm leaving!" expecting to get their way, though. I'm trying to explain to you what's going on so that you can understand what is happening so that it will "make sense to you."
 yes, unnecessary waste of time/effort

Maybe use a tuple or Tuple instead then? Even easier and less time consuming than defining a struct.
Apr 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:
 ...


 Nope, still broken.

The behavior isn't too surprising to me. Your code is buggy.

You want to explain why the code is bugguy.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
 You want to explain why the code is bugguy.

Sure. He didn't know the behavior of "==" on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:07:55 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:
 I stand corrected I guess. I'll stop thinking as well.
 ...
 Okay sure, have fun watching people use languages that make 
 more sense to them than D I guess.

*sigh* I really wish you'd be more cooperative in this conversation. I certainly don't want to drive anyone away from D. I really don't understand why someone would say "If you don't do what I want, I'm leaving!" expecting to get their way, though.

That's not quite what I'm saying. I'm just trying to make a point, which I'll repeat below.
 I'm trying to explain to you what's going on so that you can 
 understand what is happening so that it will "make sense to 
 you."

The trouble is that you've already failed before you started. People hate C++ because it's unintuitive. I can spend all day telling you about why C++'s behavior in e.g. the Abrahams-Dimov example (look it up) is _TECHNICALLY_ the correct/expected behavior. But in the end of the day it just doesn't make sense. I might win the battle, but C++ has already lost the war. So my point is, whether or not you can convince me this behavior is correct (and you probably won't), it's not going to change whether people find D easy to use. There's a reason why no other popular language (that I know of) translates "==" into a bitwise comparison of structs. What do you think the reason might be?
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
 There's a reason why no other popular language (that I know of) 
 translates "==" into a bitwise comparison of structs. What do 
 you think the reason might be?

I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
 There's a reason why no other popular language (that I know 
 of) translates "==" into a bitwise comparison of structs. What 
 do you think the reason might be?

I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.

I guess C and C++ aren't even considered languages anymore.
Apr 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:
 For fast bitwise comparison there's the "is" operator.
 The "==" operator should be "slow".
 See also http://d.puremagic.com/issues/show_bug.cgi?id=3789

Well okay. The docs will have to be updated for this issue if it's "fixed". For instance: http://dlang.org/ctod.html#structcmp In any case, I stand by that if you have a particular definition of behavior, you should provide it instead of expecting it to "just work." But I suppose using "is" is more appropriate for this type of behavior. But calling it "broken" is a bit too strong.

OK let me sum this up, as you seem confused. Whatever you think == should do, it is broken. If we assume that == should check for equality, then : pragma(msg, S("a") == S("a".idup)); writeln(S("a") == S("a".idup)); writeln(S(+0.0) == S(-0.0)); Should all evaluate to true. If == stand for identity, then they must all be false. You see that whatever is the semantic of ==, it is not properly implemented right now. Now, as we use == for equality and "is" for identity in other places (slices and objects for instance) it make sense to use the same for struct. But that another topic, as the demonstrated behavior is wrong, whatever is the semantic of ==.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
 There's a reason why no other popular language (that I know 
 of) translates "==" into a bitwise comparison of structs. What 
 do you think the reason might be?

I'm intrigued. Mind listing the languages? As far as popular languages are concerned, I'm only aware of C# having structs, but most languages don't have structs.

And don't forget Objective-C, Visual Basic (.NET), Matlab...
Apr 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 06:23:56 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:
 You want to explain why the code is bugguy.

Sure. He didn't know the behavior of "==" on structs and didn't realize it tests for identity by default. Structs require an opEquals defined to differ from this behavior.

Ho yes, so please explain what is this behavior, I'd be pleased to know.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
 The trouble is that you've already failed before you started.

Also, I'm assuming that this means that you had no intention of learning. That's kind of a poor position to be in, IMO. That means that I can't help you because you don't want to be helped. So, I can give you appropriate alternatives (such as tuple) but you won't look at it and see "Oh, jeez, that's actually what I've been using structs for." (Or not, but I can't ever know that's not what you're looking for if you're not going to even try). And I can't suggest snippets like: bool opEquals(T rhs) { foreach(i, e; this.tupleof) { if(!(e == rhs.tupleof[i])) return false; } return true; } ... Which you could use in a mixin to start building a framework of behaviors you can add to _any_ struct to automatically get the behavior you want. We also can't discuss adding this as an attribute using the new attribute system and adding it to the standard library which might be something cool. No, we have to do it _your_ way and using _your_ understanding, instead of cooperating and getting a better result that we can both agree on. All I'm saying is that structs are really basic for a reason. They're something you _build_ on. If you don't want to build on it (and you want something already somewhat built), you might be better served using something that _is_ prebuilt. Or make your own platform based on a struct (kinda like how tuples are implemented) and solve it that way. So many solutions to your problem, yet you've already decided that changing the language is the only "right" way.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:
 The trouble is that you've already failed before you started.

Also, I'm assuming that this means that you had no intention of learning.

I could tell you the same thing, but it wouldn't get me anywhere.
 All I'm saying is that structs are really basic for a reason. 
 They're something you _build_ on.

Then they shouldn't define a behavior for == in the first place. No behavior is better than wrong behavior.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:
 So many solutions to your problem, yet you've already decided 
 that changing the language is the only "right" way.

I'm just telling you that if no other language has done it, there's a reason behind it.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:
 I guess C and C++ aren't even considered languages anymore.

? main.c:13:10: error: invalid operands to binary == (have ‘struct S’ and ‘struct S’) if(a == b) You can't use == in C on structs ... ?
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:50:08 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:
 I guess C and C++ aren't even considered languages anymore.

? main.c:13:10: error: invalid operands to binary == (have ‘struct S’ and ‘struct S’) if(a == b) You can't use == in C on structs ... ?

Exactly -- when there is no correct behavior, they didn't try implementing one.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:
 I could tell you the same thing, but it wouldn't get me 
 anywhere.

Alrighty, that's my sign to leave. Good luck Mehrdad.
Apr 22 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:52:03 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:
 I could tell you the same thing, but it wouldn't get me 
 anywhere.

Good luck Mehrdad.

Same to you.
Apr 22 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:
 Same to you.

I'm going to just be a little frank with you here. I've _never_ had even a slightly productive conversation with you. You're hostile to work with. I know you have some valuable things to say and contribute to the community, but its just too difficult to work with you. If you'd make some effort at being less antagonistic, you'd find you'd get much further. Like I said in my previous large post, there are solutions out there we could talk about, but you won't hear it. Heck, you essentially didn't even acknowledge the vast majority of what I had to say in my last large post. I had plenty of neat potential solutions, but they don't even get a slight consideration on your part. What a waste of time. I half-way expect a quick backhanded reply in less than 30 seconds yet again, but I hope you consider thinking about it over night.
Apr 23 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:09:41 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:
 Same to you.

I'm going to just be a little frank with you here. I've _never_ had even a slightly productive conversation with you. You're hostile to work with. I know you have some valuable things to say and contribute to the community, but its just too difficult to work with you.

Sorry, most of my responses are really short because I'm working on other things at the moment. I'm just trying to say a few sentences to make a point and go back to what I'm doing, but it's not going as well as I would have hoped.
 If you'd make some effort at being less antagonistic, you'd 
 find you'd get much further.

 Like I said in my previous large post, there are solutions out 
 there we could talk about, but you won't hear it.

It's because you're solving a different problem than the one I'm mentioning. I'm telling you the problem (struct == behavior is wrong), you're telling me there is a workaround (tuples). I'm not looking for a workaround, I already know enough workarounds for it. I'm just trying to tell you it's a _workaround_ to a _problem_. The fact that it exists doesn't make the problem go away.
 Heck, you essentially didn't even acknowledge the vast majority 
 of what I had to say in my last large post.

Honestly, out of all the things I said, you also picked and chose single one to give nonsensical replies to. I said C and C++ and VB.NET and Matlab etc., and you just replied with "C struct doesn't even have ==". Not only did you completely miss my first point there (why aren't other languages doing the same thing?), you also missed my second point: If == doesn't make sense, it shouldn't be defined at all.
 I had plenty of neat potential solutions, but they don't even 
 get a slight consideration on your part. What a waste of time.

Again, my purpose in mentioning this wasn't to look for a workaround, but to point out the problem itself, see above. I'm not having trouble finding workarounds, I'm just pointing out examples of why people aren't finding D usable (or why they consider it broken).
Apr 23 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
 I'm not having trouble finding workarounds, I'm just pointing 
 out examples of why people aren't finding D usable (or why they 
 consider it broken).

And I know no one likes to hear something is broken. I'm not doing that to be mean or something like that, I'm doing it because when I see people forget there are usability issues in D, I think it's beneficial for me to point out [you can correct me if I'm wrong] the flaws, rather than pretend that the language is very usable and people are just too slow in adopting it.
Apr 23 2013
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
 Sorry, most of my responses are really short because I'm 
 working on other things at the moment.

 I'm just trying to say a few sentences to make a point and go 
 back to what I'm doing, but it's not going as well as I would 
 have hoped.

OK. On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
 Honestly, out of all the things I said, you also picked and 
 chose single one to give nonsensical replies to.

 I said C and C++ and VB.NET and Matlab etc., and you just 
 replied with "C struct doesn't even have ==".

I'm just replying to this because I wanted to make it clear what I did: I booted up a Linux VM and wrote a quick program to try to understand where you were coming from, taking a painstaking effort to try to understand you and the context of what you're trying to say. I didn't respond to all of the other languages because I was immediately confused by the result of the first and, additionally, trying all of the above languages would be fairly time consuming. My apologies for not trying all of them. My intention was for good when I did it, so I hope that's enough to earn forgiveness for "picking and choosing a single one to give nonsensical replies to". :-\
 Not only did you completely miss my first point there (why 
 aren't other languages doing the same thing?), you also missed 
 my second point:
 If == doesn't make sense, it shouldn't be defined at all.

Also, your second point wasn't missed. It simply didn't exist before I had started trying the C code. TBH, I think this would be a better solution. But I'd bet it'd break way too much code now.
Apr 23 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:37:29 UTC, Chris Cain wrote:
 On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
 Sorry, most of my responses are really short because I'm 
 working on other things at the moment.

 I'm just trying to say a few sentences to make a point and go 
 back to what I'm doing, but it's not going as well as I would 
 have hoped.

OK. On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:
 Honestly, out of all the things I said, you also picked and 
 chose single one to give nonsensical replies to.

 I said C and C++ and VB.NET and Matlab etc., and you just 
 replied with "C struct doesn't even have ==".

I'm just replying to this because I wanted to make it clear what I did: I booted up a Linux VM and wrote a quick program to try to understand where you were coming from, taking a painstaking effort to try to understand you and the context of what you're trying to say. I didn't respond to all of the other languages because I was immediately confused by the result of the first and, additionally, trying all of the above languages would be fairly time consuming. My apologies for not trying all of them. My intention was for good when I did it, so I hope that's enough to earn forgiveness for "picking and choosing a single one to give nonsensical replies to". :-\

Haha okay no worries, sorry my replies weren't terribly friendly. Btw there's www.ideone.com, you can also try some things there.
 Not only did you completely miss my first point there (why 
 aren't other languages doing the same thing?), you also missed 
 my second point:
 If == doesn't make sense, it shouldn't be defined at all.

Also, your second point wasn't missed. It simply didn't exist before I had started trying the C code.

Sorry I didn't realize that. :( Hope it makes sense now.
 TBH, I think this would be a better solution. But I'd bet it'd 
 break way too much code now.

I think if D wants to go anywhere, code will have to be broken, lots of it. No one's going to like it, but when it has broken features to begin with then it's not going to go very far in terms of usability.
Apr 23 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question.

That would not be a benefit, maybe. But, however, an answer to the question: "will EVER D be finished?" would be more than wonderful. Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.) Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done. D starts looking like the D in _D_uke Nukem Forever (and forever it will take...). I got old looking at D and hoping that it will ever get released. Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good. Will D remain the forever unborn child of the programming languages? Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation. At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc. I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?... Radons&Minayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained.

I don't think my boss I have to know if D is finished to let us adopt it for future products, he only want to know we'll able to create our next product with D with the same requirement and if the delay will be the same or better. For the moment due to our target platform the response is no. But if we target only Desktops the answer seems to be really close to a yes. Some libraries are missing, but there is nothing we aren't capable to write. The major issue for a boss is to accept to move "old" c++ code to trash, that was his investment, actually because there is no D developers on job market, D code isn't valuable for him. To break the vicious circle some companies have to take the risk to migrate to D and let the world know it. The easier way for a language to be inserted in companies is certainly as scripting language, just like python. Because companies doesn't consider script as really pieces of software and let developers send it to trash. It's a mistake to not considering scripts as valuable just because they are not sell.
Apr 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question. David

I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool.
Apr 23 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?
Apr 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?

Well we have 2.062 . Let's decide this is stable version. 2.062.1 will go out then 2.062.2, etc . . . They contains only fixes with really small (I mean almost non existent) breakage, no new feature, only fix of ICE, codegen bugs, etc . . . And 2.063 can still be pushed in the meantime. The thing that with D, you hit compiler bugs and so on, and you can't get fixes without getting the new version that break half of your code.
Apr 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?

Fix it in latest version. Leave it broken in stable.
Apr 23 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 08:18:08 UTC, Dicebot wrote:
 On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable 
 version that is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?

Fix it in latest version. Leave it broken in stable.

I'm not convinced that's terribly useful but if you think so then ok...
Apr 23 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question. David

I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool.

Okay, maybe it was somewhat of a trick question after all: "Tourist" put it as if all that was required was to mark a certain version stable, and I wanted to hint at the fact that this alone wouldn't help anybody at all. David
Apr 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code

So what happens when a flaw in the language is fixed? Do you fix it and break code, or do you leave it broken?

I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version. During the meantime, users could live with workarounds and "forbidden to do that!". Look at C and MISRA-C. It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools. A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions. C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers. Being predictable does matter sometimes. Tools matter too.
Apr 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 08:23:34 UTC, David Nadlinger wrote:
 Okay, maybe it was somewhat of a trick question after all: 
 "Tourist" put it as if all that was required was to mark a 
 certain version stable, and I wanted to hint at the fact that 
 this alone wouldn't help anybody at all.

 David

Sure. If "naming" is only thing required, than anyone can name it and no D team effort is needed :) Unfortunately, it is not that simple.
Apr 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
It is simply impossible for D. Defining trait for C/C++ is very 
strict and formal standard paper which completely defines the 
language. Revise of standard is decoupled with compiler releases. 
Standard can be revised once in a 10 years but compilers keep 
evolving having this paper in mind.

D has reference compiler and thus you technically suggest to stop 
releasing any compiler version for 1-2 years. Ugh.

On Tuesday, 23 April 2013 at 08:33:05 UTC, eles wrote:
 I am more for following the C/C++ solution: periodical revise 
 the language, but not every two months. Several years and once 
 that the compiler infrastructure is already in place and 
 tested, publish (officially) the new version.

 During the meantime, users could live with workarounds and 
 "forbidden to do that!". Look at C and MISRA-C.

 It won't help to declare a stable version of D, while keep 
 adding new things. What would really help is to stop adding new 
 things, remove those that we are in doubt if they are good or 
 no (properties?) or, at least, leave them as they are, then 
 move towards improving the tools.

 A cleaner language with better tools will allow D to take off, 
 while still leaving room for possible improvements in future 
 revisions.

 C++ did not start as a perfect language, nor it has become, 
 still there are tools for it, people are using it, companies 
 are hiring C++ developers.

 Being predictable does matter sometimes. Tools matter too.

Apr 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
 D has reference compiler and thus you technically suggest to 
 stop releasing any compiler version for 1-2 years. Ugh.

No. Stop adding things. Besides that, what's the alternative?
Apr 23 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bacbaa005298c04db03bd27
Content-Type: text/plain; charset=ISO-8859-1

On 23 April 2013 09:56, eles <eles eles.com> wrote:

 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:

 D has reference compiler and thus you technically suggest to stop
 releasing any compiler version for 1-2 years. Ugh.

No. Stop adding things. Besides that, what's the alternative?

Adding things isn't a problem and does not affect already existing code. Perhaps you meant changing behaviours and removing things? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7bacbaa005298c04db03bd27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 3 April 2013 09:56, eles <span dir=3D"ltr">&lt;<a href=3D"mailto:eles eles.= com" target=3D"_blank">eles eles.com</a>&gt;</span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <div class=3D"im">On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:= <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> D has reference compiler and thus you technically suggest to stop releasing= any compiler version for 1-2 years. Ugh.<br> </blockquote> <br></div> No. Stop adding things.<br> <br> Besides that, what&#39;s the alternative?<br> </blockquote></div><br></div><div class=3D"gmail_extra">Adding things isn&#= 39;t a problem and does not affect already existing code.=A0 Perhaps you me= ant changing behaviours and removing things?<br clear=3D"all"></div><div cl= ass=3D"gmail_extra"> <br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#= 39;0&#39;; </div></div> --047d7bacbaa005298c04db03bd27--
Apr 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote:
 On 23 April 2013 09:56, eles <eles eles.com> wrote:

 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:

 D has reference compiler and thus you technically suggest to 
 stop
 releasing any compiler version for 1-2 years. Ugh.

No. Stop adding things. Besides that, what's the alternative?

Adding things isn't a problem and does not affect already existing code. Perhaps you meant changing behaviours and removing things?

Any addition in D can be breaking wconsidering feature like is(typeof(blah))
Apr 23 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 08:56:37 UTC, eles wrote:
 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
 D has reference compiler and thus you technically suggest to 
 stop releasing any compiler version for 1-2 years. Ugh.

No. Stop adding things. Besides that, what's the alternative?

We don't have formal spec. Bug-fixing changes can't be differentiated from "new" changes. My ancient proposal is still in the newsgroup : http://forum.dlang.org/post/nchvayzsbrzevvucmmmi forum.dlang.org
Apr 23 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 23 April 2013 at 07:43:21 UTC, Flamaros wrote:
 On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger 
 wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
 What's holding you from releasing a version now and 
 declaring it stable for e.g. a year?

What would be the benefit of just declaring one release stable? This is not a trick question.

That would not be a benefit, maybe. But, however, an answer to the question: "will EVER D be finished?" would be more than wonderful. Clean up the doubtful or wrong features and let it as it is. Further language improvements should be made after several years of use. Much like C++ is evolving with its standards, also C (C89, C99 etc.) Seriously, now, D is in the making for a decade and more. And, until it gets stable and Walter STOPS working on D (language) and, instead, only works on the COMPILER, things are not done. D starts looking like the D in _D_uke Nukem Forever (and forever it will take...). I got old looking at D and hoping that it will ever get released. Imagine that Bjarne Stroustrup would proceed today with changing C++ at the same pace as D is. C++ still evolves, albeit less fast than D, but also with much more scrutinity and, let's say, conservatorism. Which, after a while, it is good. Will D remain the forever unborn child of the programming languages? Born it. Let it become what is intended to be: a MATURE language. Yes, it might not grow perfect, but it will grow. It needs to get into childhood, enough with the (pro-)creation. At my job I went back to C++. With a language contunously in the making, the tools will never mature enough, never will get Eclipse plugins as good as CDT, never etc. I have that feeling (correct me if I am wrong) that C++ will catch up with D in several years. Look at C++11, it is a nice improvement. C++14 will be (hopefully) even better. And, then?... Radons&Minayev made a good decision to quit D back then and never look behind. A toy it was, a toy remained.

I don't think my boss I have to know if D is finished to let us adopt it for future products, he only want to know we'll able to create our next product with D with the same requirement and if the delay will be the same or better. For the moment due to our target platform the response is no. But if we target only Desktops the answer seems to be really close to a yes. Some libraries are missing, but there is nothing we aren't capable to write. The major issue for a boss is to accept to move "old" c++ code to trash, that was his investment, actually because there is no D developers on job market, D code isn't valuable for him. To break the vicious circle some companies have to take the risk to migrate to D and let the world know it. The easier way for a language to be inserted in companies is certainly as scripting language, just like python. Because companies doesn't consider script as really pieces of software and let developers send it to trash. It's a mistake to not considering scripts as valuable just because they are not sell.

The hardest selling point for systems programming languages is to get them adopted by an OS vendor, until then they are just another tool for business applications, a field already too crowded nowadays. Look at C++, only in the last decade did OS vendors start coding operating systems in C++, instead of plain C, to the point that C is now considered legacy at Microsoft. Who knows how long it will take for another vendor to pick up D for such use cases, even if it was 100% stable today? These things take a long time, even programmer generations. -- Paulo
Apr 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu 
wrote:
 I think we shouldn't follow the C++ model. Whatever made C++ 
 successful is not what'll make D successful. The context and 
 expectations are very different now.

 Andrei

That's a pretty vague assertion. Please define the model that you have in mind for D. OK. Don't follow the C++ model. But, then, what is the model that D follows? Is there any such model?
Apr 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
wrote:
 On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu

of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei

As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.
Apr 23 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:
 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
 wrote:
 On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu

of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei

As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.

I don't see on what C++14 will really change the current state of C++? Changes aren't import for every day developments, C++14, won't import fast build, safe language specifications (removal of multiple inheritance, no removal of error prone syntaxes, specified initialization values, mandatory override keyword, ...),... D don't have to compete C++, let D maturate. If you are hurry to see D in the industry maybe you can contribute on tools, libraries,...
Apr 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 23, 2013 07:02:39 Mehrdad wrote:
 Well, I think the float behavior is correct and the string
 example is broken, but that wasn't my point anyway.
 
 The point was that it's still broken.

According to TDPL (section 7.1.5.2, p. 258 - 259), == on structs should be equivalent to using == on each of the struct's members: http://d.puremagic.com/issues/show_bug.cgi?id=3789 Doing anything else would be inconsistent, and the way that it is has definitely been causing problems and forces people to overload opEquals way more often than strictly speaking should be necessary. - Jonathan M Davis
Apr 23 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:
 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:


Sorry, I was rude here and I apologize. Finally, D is (at least) a wonderful place to discuss and test new ideas and, while I would like it to take off faster, a too early rush won't make any good.
Apr 26 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:
 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
 wrote:
 On 4/23/13 2:42 PM, eles wrote:
 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu

of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei

As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view.

I also think when modules are integrated into the C++ standard, for most developers, there won't be any case left for D. Even though D technically is superior in almost every way, conservatism is strong enough.
Apr 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
 I also think when modules are integrated into the C++ standard, 
 for most developers, there won't be any case left for D. Even 
 though D technically is superior in almost every way, 
 conservatism is strong enough.

C++ will never be sufficiently changed to leave no chance for other native languages. It is doomed because of mandatory backwards compatibility with huge legacy package. Main issues of C++ are not lack of advanced features but inconvenient design of basic features. Well, D is trying to have its own share of those issues too :P
Apr 28 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
 True, but only now the major OS vendors are switching from C to 
 C++ as their main systems programming language.

Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming?
Apr 28 2013
prev sibling next sibling parent "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Which vendors have switched to C++ for systems programming?

Paolo probably had MS in mind which didn't release WinRT for C.
Apr 28 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 29 April 2013 at 04:19:06 UTC, Oleg Kuporosov wrote:
 On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Which vendors have switched to C++ for systems programming?

Paolo probably had MS in mind which didn't release WinRT for C.

Ah ok... but that's not really "systems programming", it's pretty high-level.
Apr 28 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
 Am 28.04.2013 12:03, schrieb Dicebot:
 On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:
 I also think when modules are integrated into the C++


C++ as their main systems programming language.

I think that exactly because it is a switch *in the happening*, it is the moment for D to be involve in that switch. Because project managers are considering switching and they look for alternatives. Maybe some of them will tell themselves: "well, if we switch, why do not take that D in consideration? at least, for experimenting and see what it gives". It is useless to be a good alternative if nobody wants to switch. If they go down on the C++ path, then two things will happen: -they will be even more reluctant to do another switch, while their code base matures (and, do not forget, interoperability or portability from C to D is one thing; form C++ to D is a different, huge, beast). -C++ will get more traction and more pressure to improve itself, from vendors and community at large. it will advance faster. In the end, we should not be sorry, as programmers we will win better language, better tools. But I am afraid that D will not win as much.
Apr 28 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
 ...

D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.
Apr 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
 On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
 D is simply in no shape to compete for kernels for same reasons 
 it is rather painful to use in embedded (fat runtime, language 
 features relying on hidden gc allocations etc.) It is hardly 
 practical to discuss the moment to compete when it is not an 
 option from technical point of view.

Well, then a list of what's still missing should be compiled (in terms of features and language changes, not in terms of bugs). An rush to complete it. Some of the issues were discussed since many months, and no definitive decision has been taken (see the property). I am rather in favor of taking a decision, good or bad, than to prolonge ambiguity. Also for several minor issues (ie: double[$] static arrays and __MODULE__ identifier and so on). For those, I would like to see a more accelerated pace. I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation.
Apr 29 2013
prev sibling next sibling parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote:
 I even start thinking that is better to release a new feature 
 after a relative short, preliminary discussion, and be prepared 
 to change it during a time frame, if it is not as practical as 
 desired, instead of prolonging a discussion for centuries in 
 the search of the perfect implementation.

That brings us back to the "Stable D" subject, and the separation between stable and unstable. Those preliminary features should be included in the unstable releases, where changes can be made without the fear of breaking things. Then, after some actual usage, they would be merged to the stable branch.
Apr 29 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:
 True, but only now the major OS vendors are switching from C 
 to C++ as their main systems programming language.

Curious, which ones are you referring to? Windows uses C for the kernel, for many reasons, one of which is that C (unlike C++) discourages storing large objects on the stack. Linux uses C for the kernel too, mainly because Walter hates C++ (and C++ programmers). Which vendors have switched to C++ for systems programming?

BeOS/Haiku - C++ Symbian - C++ MacOS X - Device Drivers are written in a C++ subset (IOKit) z/OS - Original code was Modula-2/Assembly, with new code being C++ Windows - WinRT is C++, C is considered legacy, Herb Sutter stated at BUILD 2012 that Windows team is making kernel code C++ compatible. I can search for the exact minute in the videos if you wish.
Apr 29 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:
 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Linux uses C for the kernel too, mainly because Walter hates 
 C++ (and C++ programmers).

err, Linus
Apr 29 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:
 On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
 ...

D is simply in no shape to compete for kernels for same reasons it is rather painful to use in embedded (fat runtime, language features relying on hidden gc allocations etc.) It is hardly practical to discuss the moment to compete when it is not an option from technical point of view.

This guys don't have any issues selling Oberon compilers for embedded use. http://www.oberonday2011.ethz.ch/talks/armembedded.pdf http://www.astrobe.com/default.htm A GC enabled systems programming language. Oracle with their Spots and the new Keil board support (Java) http://www.sunspotworld.com/ http://docs.oracle.com/javame/config/cldc/rel/3.3/keil/gs/html/getstart_rtx/running.htm Or the Netduino guys (C#) http://netduino.com/ Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards.
Apr 29 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
 This guys don't have any issues selling Oberon compilers for 
 embedded use.
 ...

That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.
Apr 29 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote:
 On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:
 This guys don't have any issues selling Oberon compilers for 
 embedded use.
 ...

That is simple, "embedded" is a buzzword often understood as "something like PC but small". Such definition is quite useless because it implies no specific requirements. Like, calling modern ARM smartphone an embedded system? No way. You can even afford to have something as inefficient as kernel in Java on those machines, why not. Much more practical definition of "embedded" is all about specific requirements. Real-time systems, systems with hard memory restrictions (imagine coding in environment where malloc is prohibited because every single byte of physical memory is pre-allocated). Those can vary from microchips to monstrous servers and I don't see anything but C or C++ with lot of custom policies used there.

Quoting myself "Or course this is a very limited subset of what embedded is all about, but I think D could also be usable in such types of boards."
Apr 29 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:
 Quoting myself

 "Or course this is a very limited subset of what embedded is all
 about, but I think D could also be usable in such types of 
 boards."

Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own.
Apr 29 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 11:24:02 UTC, Dicebot wrote:
 On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:
 Quoting myself

 "Or course this is a very limited subset of what embedded is 
 all
 about, but I think D could also be usable in such types of 
 boards."

Okay, pardon me, may be I have not highlighted my point clear enough: there is no real market for D in that limited subset because it has to compete with Java, C# or any modern language based on their virtual machines. And, similar to desktop usage, lot of selling points for D are lost then, because, well, why bother? Contrary to this, any language who can make it into real embedded domain will be almost uncontested, because this industry is still stuck with 40-year obsolete tools. But that is not something that may happen on its own.

Fair enough, I agree with you there.
Apr 29 2013