www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why do some language-defined attributes have and some not?

reply Shriramana Sharma via Digitalmars-d-learn writes:
Hello. See http://dlang.org/attribute. 3 attributes starting at
http://dlang.org/attribute#disable have a   in front. Apparently safe,
trusted and system also do, though these are documented elsewhere:
http://dlang.org/function.html#function-safety.

Why are some language-defined attributes starting with   and others
not? Wouldn't it be consistent and less-confusing to, say, only use  
for user-defined attributes and not these language-defined ones?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா
श्रीरमणशर्मा
Oct 22 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 22 October 2014 at 19:13:58 UTC, Shriramana Sharma 
via Digitalmars-d-learn wrote:

 Hello. See http://dlang.org/attribute. 3 attributes starting at
 http://dlang.org/attribute#disable have a   in front. 
 Apparently safe,
 trusted and system also do, though these are documented 
 elsewhere:
 http://dlang.org/function.html#function-safety.

 Why are some language-defined attributes starting with   and 
 others
 not? Wouldn't it be consistent and less-confusing to, say, only 
 use  
 for user-defined attributes and not these language-defined ones?


It's a historical thing. Walter didn't want to add more keywords, 
so we put   in the front of some of the new ones. User-defined 
attributes didn't even exist at the time. Those were added far 
later. It would be nice if none of the built-in attributes had   
on them, but it's far too late now. And by the way, there's also 
 property, so there's four of them with  .

- Jonathan M Davis
Oct 22 2014
next sibling parent reply Shriramana Sharma via Digitalmars-d-learn writes:
I thought D was beyond carrying historical baggage. DMD 2.x is not
necessarily language-compatible with DMD 2.(x+1) since the language is
still evolving. You can deprecate one syntax and enforce the other in
a later version.

I submit that the syntax for attributes should be streamlined. Shall I
go and open a Bugzilla item?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா
श्रीरमणशर्मा
Oct 22 2014
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma 
via Digitalmars-d-learn wrote:

 I thought D was beyond carrying historical baggage. DMD 2.x is 
 not
 necessarily language-compatible with DMD 2.(x+1) since the 
 language is
 still evolving. You can deprecate one syntax and enforce the 
 other in
 a later version.

 I submit that the syntax for attributes should be streamlined. 
 Shall I
 go and open a Bugzilla item?


LOL. I understand the sentiment, but it's a waste of time. We've 
long since reached the point where we try and not break people's 
existing code unless we have a really good reason for it (and for 
better or worse, aesthetics definitely don't make the cut). No, 
D2 is not as fixed in stone as C++ is, but we are trying to have 
a stable enough language for programmers to use in production 
rather than treating the language as being experimental and/or 
rapidly changing in incompatible ways.

So, yes, we do have historical baggage, albeit nowhere near as 
much as C++ does. But the reality of the matter is that _every_ 
language that gets used in production has historical baggage, 
because you never get everything right, and you frequently can't 
afford to change it, because it would break too many existing 
programs. And for better or worse, fixing attribute names doesn't 
even come close to being on the list of things that Walter Bright 
would consider worth changing. It's hard enough to get him to 
agree to make breaking changes when most of us agree that we'll 
be better off with the changes in spite of the code breakage that 
they cause, let alone on a controversial topic like attribute 
names which has been discussed to death.

Walter and Andrei very much want D to be being used in production 
at this point, and so the focus on features is entirely on what's 
required to make the language fully usuable for companies looking 
to use D, and tweaking things to make them cleaner just isn't 
going to happen without a really good, practical reason for it. 
Breaking changes are sometimes made still, but not for something 
like that

- Jonathan M Davis
Oct 22 2014
next sibling parent Shriramana Sharma via Digitalmars-d-learn writes:
On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:

 So, yes, we do have historical baggage, albeit nowhere near as
 much as C++ does.


OK understood, but I may just go and file that bug so that if there is
a future D 3 series, then stuff like this can be cleaned up. :-) I'm
finicky like that! ;-)


 Walter and Andrei very much want D to be being used in production
 at this point,


We all do, no? Not only those two! :-)

So I agree with you that for now this is not an urgent need. I guess
when we clean out all that !> <>= stuff this can be done too, or
something like that...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா
श्रीरमणशर्मा
Oct 22 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 23 October 2014 at 02:22:41 UTC, Jonathan M Davis 
wrote:

 On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma 
 via Digitalmars-d-learn wrote:

 LOL. I understand the sentiment, but it's a waste of time.


Jonathan,

I agree It's impossible to debate such thing with Walter / Andrej 
right now, but I don't think It's a waste of time: every explicit 
and accountable opinion about that is a little stone to weigh in 
the balance.

---
/Paolo
Oct 22 2014
prev sibling parent "H. S. Teoh via Digitalmars-d-learn" <digitalmars-d-learn puremagic.com> writes:
On Thu, Oct 23, 2014 at 10:50:07AM +0530, Shriramana Sharma via
Digitalmars-d-learn wrote:
[...]

 So I agree with you that for now this is not an urgent need. I guess
 when we clean out all that !> <>= stuff this can be done too, or
 something like that...


[...]

I believe those flying-saucer operators (:-P) are slated for removal.
IIRC, Walter has recently actually made some PRs to deprecate those
operators, which means in a couple o' releases they should finally be
gone for good.


T

-- 
Shin: (n.) A device for finding furniture in the dark.
Oct 22 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma 
via Digitalmars-d-

 I submit that the syntax for attributes should be streamlined. 
 Shall I
 go and open a Bugzilla item?


No need: http://wiki.dlang.org/DIP64
Oct 23 2014
parent reply "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby
wrote:

 On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma 
 via Digitalmars-d-

 I submit that the syntax for attributes should be streamlined. 
 Shall I
 go and open a Bugzilla item?


 No need: http://wiki.dlang.org/DIP64


Besides the   symbols, isn't there also some inconsistency on
whether attributes go before or after the declaration?

 property public static void foo() const  safe pure nothrow

I've never bothered to ascertain how much of the positioning is
optional, but definitely none of it makes sense.
Oct 24 2014
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, October 24, 2014 23:38:38 Chris Williams via Digitalmars-d-learn 
wrote:

 On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby

 wrote:

 On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
 via Digitalmars-d-


 I submit that the syntax for attributes should be streamlined.
 Shall I
 go and open a Bugzilla item?


 No need: http://wiki.dlang.org/DIP64


 Besides the   symbols, isn't there also some inconsistency on
 whether attributes go before or after the declaration?

  property public static void foo() const  safe pure nothrow

 I've never bothered to ascertain how much of the positioning is
 optional, but definitely none of it makes sense.


Yeah. Some attributes are legal on both sides, others on only one, and I'm not
aware of much logic to it (though at the moment, I don't think that there are
any that are only legal on the right, so you could get away with just putting
them all on the left). I think that it's primarily attributes that exist in
other languages (and go on the left in those languages) that have to go on the
left (e.g. public, private, static). Most (all?) of the D-specific ones can go
on both sides. The ones that actually cause problems with that though are
const, immutable, inout, and shared, because without parens, when they're put
on the left, they still affect the function and not the return type, so quite
a few of us have argued that they should be illegal on the left.

- Jonathan M Davis
Oct 24 2014
prev sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 23 Oct 2014 06:29:12 +0530
Shriramana Sharma via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 I submit that the syntax for attributes should be streamlined. Shall I
 go and open a Bugzilla item?


hehe.
https://issues.dlang.org/show_bug.cgi?id=3D13388
https://issues.dlang.org/show_bug.cgi?id=3D13397
i must admit that there were NO "code breaking" in both of that, and
in NG discussion people telling about newcomers asking "why that ' '
is here but not there".

besides, no "serious" language can live without "legacy". legacy is a
sign of maturity. ;-)
Oct 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via 
Digitalmars-d-learn wrote:

 besides, no "serious" language can live without "legacy". 
 legacy is a sign of maturity. ;-)


So you are basically saying that D is a teenager for whom wearing 
ugly make-up is a sign of maturity?
Oct 23 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 23 Oct 2014 07:47:00 +0000
via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:


 On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 besides, no "serious" language can live without "legacy".=20
 legacy is a sign of maturity. ;-)


=20
 So you are basically saying that D is a teenager for whom wearing=20
 ugly make-up is a sign of maturity?


exactly. it seems to me that some D developers have strange feeling
that accumulating legacy will show D maturity and will help D to become
more widespread. despite all "#breakourcode" requests from real D users.
Oct 23 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via 
Digitalmars-d-learn wrote:

 On Thu, 23 Oct 2014 07:47:00 +0000
 via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> 
 wrote:


 On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via 
 Digitalmars-d-learn wrote:

 besides, no "serious" language can live without "legacy". 
 legacy is a sign of maturity. ;-)


 
 So you are basically saying that D is a teenager for whom 
 wearing ugly make-up is a sign of maturity?


 exactly. it seems to me that some D developers have strange 
 feeling
 that accumulating legacy will show D maturity and will help D 
 to become
 more widespread. despite all "#breakourcode" requests from real 
 D users.


I would be very surprised if anyone thinks that. It's a question 
of what breakage is worth making and the fact that every time we 
break people's code, we risk ticking users off and scaring them 
away. It doesn't work to become widespread - particularly in 
production - when you frequently break people's code (even with a 
good reason), and breakage needs a good reason even when it's 
rare. Deciding whether a particular change is worth making is 
always a subject of big debate. There _are_ cases where most 
everyone agrees and yet Walter won't make the change, but there 
are also plenty where there definitely isn't a consensus. For 
attributes, there's a consensus that the situation is not ideal, 
but there definitely isn't a consensus on what we should do about 
it or whether it's worth breaking code to fix it. And because 
it's pretty much an aesthetic thing, it's exactly the sort of 
thing where it would be very difficult to convince Walter or 
Andrei to make the change (especially Walter). Making the change 
won't fix any bugs and won't prevent any bugs, so it's a hard 
sell.

Regardless, no one is actually aruging that we want to leave any 
kind of legacy cruft in the language just so that we have legacy 
cruft and therefore look mature. It comes down to whether fixing 
that legacy cruft is worth it when everything else is taken into 
account, and because we are very much trying to make it so that D 
is mature enough to be used in production and gets wider 
adoption, the bar that something has to pass in order to be 
considered worth changing (particularly by Walter) is much, much 
higher than it would have been a few years ago.

- Jonathan M Davis
Oct 23 2014
parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 23 Oct 2014 21:33:00 +0000
Jonathan M Davis via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 On Thu, 23 Oct 2014 07:47:00 +0000
 via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>=20
 wrote:


 On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via=20
 Digitalmars-d-learn wrote:

 besides, no "serious" language can live without "legacy".=20
 legacy is a sign of maturity. ;-)


=20
 So you are basically saying that D is a teenager for whom=20
 wearing ugly make-up is a sign of maturity?


 exactly. it seems to me that some D developers have strange=20
 feeling
 that accumulating legacy will show D maturity and will help D=20
 to become
 more widespread. despite all "#breakourcode" requests from real=20
 D users.


=20
 I would be very surprised if anyone thinks that. It's a question=20
 of what breakage is worth making and the fact that every time we=20
 break people's code, we risk ticking users off and scaring them=20
 away. It doesn't work to become widespread - particularly in=20
 production - when you frequently break people's code (even with a=20
 good reason), and breakage needs a good reason even when it's=20
 rare.


and those poor souls who already commited to D often just can't run
away, so they can stand alot annoying things, even if they praying to
break their code. this is J. Random, The Reddit User who really
matters. J. Random never used D for anything more complex than "hello,
world", but maybe he will write another "hello, world", and if we'll
change that inconsistent feature, which annoys alot of actual users, J.
Random will scream in pain! even if "changing the feature" means at
least one year of deprecation first, and J. Random's "hello, world"
will work for this year, and compiler will guide him in fixing his
code.

why can't i see that J. Random in recent discussion about deprecating
prefix 'const'? the universal answer was: "yes, break our code NOW!
PLEASE!" including people from the companies with big D codebases.

will it help if we'll start reddit campaigns instead of trying to talk
in this NGs? seems that J. Random The Reddit User has much more
influence on decisions like that.


 Deciding whether a particular change is worth making is=20
 always a subject of big debate.


...and then someone will come and say: "no, we won't do that despite
anything you wrote here."


 There _are_ cases where most=20
 everyone agrees and yet Walter won't make the change, but there=20
 are also plenty where there definitely isn't a consensus. For=20
 attributes, there's a consensus that the situation is not ideal,=20
 but there definitely isn't a consensus on what we should do about=20
 it or whether it's worth breaking code to fix it.


i bet alot of people just tired of endless talking which leads nowhere.
heh, the strongest argument that can stop almost any discussion is
"well, try to convinve Walter". Walter is very talented person, he's
great person, and he is open to discussion, but it seems to me that he
has very solid picture of what he wants D to be and don't want to
change small things that are OK for him, but annoying for others. but
those "small issues that barely worth changing" tend to accumulate and
hurt the whole language.


 And because=20
 it's pretty much an aesthetic thing, it's exactly the sort of=20
 thing where it would be very difficult to convince Walter or=20
 Andrei to make the change (especially Walter). Making the change=20
 won't fix any bugs and won't prevent any bugs, so it's a hard=20
 sell.


yes, that things just making life a little easier for D users. take me,
for example: i still can't remember where i should put that ' ' and
where i shouldn't. it's not on top of my fingers and it has no logic
behind, so trying to remeber such thing breaks me out of my "thinking
stream". and this is so easy to fix that this annoys me each time. and
while it left unfixed, we accumulating more and more D code, making
fixing this thing in future close to impossible, 'cause it will really
break huge codebases.

aestetic things matters alot.


 Regardless, no one is actually aruging that we want to leave any=20
 kind of legacy cruft in the language just so that we have legacy=20
 cruft and therefore look mature.


yes, i'm sarcastic when saying this, and when i'm saying that "existing
D users are second-class citizens", but how else can i show that this
issues *matters* *alot*?


 and because we are very much trying to make it so that D=20
 is mature enough to be used in production


people from companies which using D tells that it will be good to make
some code-breaking change and this change will made their codebases
easier to maintain and will make code from new developers less
error-prone. and... they are mostly ignored. so it seems to me that
having some useless legacy is the only way to sell D to some
"enterprise production".


 the bar that something has to pass in order to be=20
 considered worth changing (particularly by Walter) is much, much=20
 higher than it would have been a few years ago.


that's where my sarcastic "legacy means maturity" was born.

i love D and i want D to be widespread, but what makes me love D is
it's attitude to fixing stupid legacy we have in C and C++. and now it
seems to me that someone should start "BetterD" project to fix legacy
we already have in D. ain't the desire to fix legacy cruft was one of
the big driving forces of D creation? it's a pity for me to see that D
starting to follow some of the worst C++ aspects.
Oct 23 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via 
Digitalmars-d-learn wrote:

 i love D and i want D to be widespread, but what makes me love 
 D is
 it's attitude to fixing stupid legacy we have in C and C++. and 
 now it
 seems to me that someone should start "BetterD" project to fix 
 legacy
 we already have in D. ain't the desire to fix legacy cruft was 
 one of
 the big driving forces of D creation? it's a pity for me to see 
 that D
 starting to follow some of the worst C++ aspects.


_Every_ language ends up with legacy cruft if it ever gets any 
kind of widespread use in the real world. If you want a language 
that never has legacy cruft, I expect that you will be forever 
disappointed. The question is what is and is worth changing and 
at whether you ever reach the point that you're _never_ allowed 
to break code (which is pretty much where C++ is). I certainly 
hope that D never reaches the point that we'll never break code 
even when it truly makes sense to do so, but we _have_ reached 
the point where the reasons have to be much stronger.

Some stuff that could currently be considered legacy cruft will 
probably be changed, but it's generally a hard sell, particularly 
because Walter is _very_ paranoid about breaking people's code 
(arguably too much so). Though it should be noted that the vast 
majority of D users never post in the newsgroup, and many of them 
probably have never visited it, so basing anything on what's 
discussed in the newsgroup is basing it on the most dedicated 
users, which aren't necessarily representative of the user base 
sa a whole, which always makes it difficult to figure out which 
decisions that would break code are okay and which aren't and is 
probably part of why Walter overreacts to some of the comments on 
places like reddit.

Regardless, you can certainly try and lobby for the attribute 
names to be normalized, but I don't expect it to change, in this 
particular case, while I'd certainly be open to it if Walter want 
to get rid of all of the  s on all of the built-in attribute 
names, I also don't really care if they stay the way they are. 
It's a minor annoyance, but I never found it hard to learn which 
ones had   on them and which didn't (just treat it like one extra 
letter to learn in the keyword), and I'm light years beyond the 
point where I memorized them all. The primary annoyance about it 
at this point is having to answer questions on it when yet 
another user tries to figure out why some have   and some don't 
as if there's a discernable pattern to it, and there isn't. And 
that sucks, but it doesn't actually cause bugs (unlike allowing 
const on the left-hand side of a member function, which 
definitely should be deprecated), and it's actually pretty easy 
to explain.

- Jonathan M Davis
Oct 23 2014
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 10/24/2014 7:20 AM, ketmar via Digitalmars-d-learn wrote:


 why can't i see that J. Random in recent discussion about deprecating
 prefix 'const'? the universal answer was: "yes, break our code NOW!
 PLEASE!" including people from the companies with big D codebases.


There are people out there using D who do not participate in the 
newsgroups. Walter has told us before that he gets emails from companies 
using D in production. He has to deal with complaints about code 
breakage that we aren't going to see here in the NG. Just keep in mind 
that no matter how many of us here agree on a breaking change, we are 
not the entirety of the D user base. And it has nothing to do with Reddit.
Oct 23 2014
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:

 There are people out there using D who do not participate in 
 the newsgroups. Walter has told us before that he gets emails 
 from companies using D in production. He has to deal with 
 complaints about code breakage that we aren't going to see here 
 in the NG. Just keep in mind that no matter how many of us here 
 agree on a breaking change, we are not the entirety of the D 
 user base. And it has nothing to do with Reddit.


I think that Walter talked about emails complaining about "silent 
breakage" or "regressions", and that's a totally different matter.

To be honest, I only remember that he talked about one single 
case, but maybe I'm wrong.
And I don't remember any complain about code deprecations.
---
/Paolo
Oct 24 2014
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, October 24, 2014 08:19:48 Paolo Invernizzi via Digitalmars-d-learn 
wrote:

 On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:

 There are people out there using D who do not participate in
 the newsgroups. Walter has told us before that he gets emails
 from companies using D in production. He has to deal with
 complaints about code breakage that we aren't going to see here
 in the NG. Just keep in mind that no matter how many of us here
 agree on a breaking change, we are not the entirety of the D
 user base. And it has nothing to do with Reddit.


 I think that Walter talked about emails complaining about "silent
 breakage" or "regressions", and that's a totally different matter.

 To be honest, I only remember that he talked about one single
 case, but maybe I'm wrong.
 And I don't remember any complain about code deprecations.


Walter doesn't seem to understand that unintended breakage and planned,
communicated breakage via a proper deprecation process are two totally
different issues. He's definitely had folks complain about regressions, and
the response to that has sometimes been that changes that we were considering
got axed, because he'd just had someone complain about (unintended) code
breakage, and for him, that meant that pretty much _anything_ which would
eventually result in code breakage was bad and therefore raised the bar on
changes that much more (IIRC, that happened just after the virtual keyword had
been introduced, and the result was that it was removed, and the plans to
switch to final by default were axed).

So no, I don't think that folks have complained to him about deprecations
(though they could have, and he just never said anything about it), but they
have complained often enough about other stuff, and he doesn't seem to
distinguish between planned breakage and unintentional breakage in the same
way that many of the rest of us do.

- Jonathan M Davis
Oct 24 2014
prev sibling parent reply Shriramana Sharma via Digitalmars-d-learn writes:
Hi people and thanks for weighing in. It's nice to note that there's
already a DIP on this. I hope it's refined and implemented in a future
version in a meaningful manner. Is it OK to edit the wiki to add one's
opinions?

And in this case, personally I'm not sure why people are talking about
code *breakage*, which is a big word IMO. It's after all removing or
adding   in a few cases. It's relatively straightforward a fix to
automate. If there can be a dfix to relocate the const from before to
after the function name, then this should be much easier, no? It
wouldn't even need a D3, but could be done in a future D2 point
release. And as someone else said, there's a difference between
outright breakage and planned deprecation.

As for the cases when serious changes to the grammar are needed, I
feel the Py2 to Py3 transition is a good example to emulate. Lots of
cleanup happened in Py3, Py2 is still supported, and there exists
tools like 2to3 and six (https://pypi.python.org/pypi/six) to help
people bridge the gap.

Finally in general I'd also like to suggest that rather than saying
something like "you won't be able to convince Walter of this because
it's not important", which IMHO tends to somewhat put off newbies who
are excited by the language and want to contribute, and tends to put
the project masters in an autocratic light (which people won't like to
hear), one might consider saying something like "D 2 is now aiming for
stability so we are trying to minimize the number of grammar changes".

Thanks again, all!

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா
श्रीरमणशर्मा
Oct 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 24 October 2014 at 14:23:04 UTC, Shriramana Sharma via 
Digitalmars-d-learn wrote:

 As for the cases when serious changes to the grammar are 
 needed, I
 feel the Py2 to Py3 transition is a good example to emulate. 
 Lots of
 cleanup happened in Py3, Py2 is still supported, and there 
 exists
 tools like 2to3 and six (https://pypi.python.org/pypi/six) to 
 help
 people bridge the gap.


I agree that " "-stuff is trivial, but I don't think Python sets 
a good example. The codebase is basically divided in two, 
libraries have to support both, and I think they should have 
changed more if going to the trouble.

In essence you should either change so little that upgrading is 
trivial or you should improve the language enough to ensure that 
all new projects choose the improved language.

However, Python is in widespread use on a fairly massive scale 
and is dynamic, which makes breaking very serious as it happens 
at runtime.

D could with little trouble undergo a massive change where the 
static type system catch the issues and call it D3.

The real problem is that there is no design for a D3 rooted in a 
semantic model that is clean. Such a transition would require a 
solid formal specification where you eliminate all weird aspects.

But I don't think anyone is working on a new spec? I am willing 
to help out if other people are interested.
Oct 24 2014
parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 24 October 2014 at 15:06:25 UTC, Ola Fosheim Grøstad 
wrote:

 I agree that " "-stuff is trivial, but I don't think Python 
 sets a good example. The codebase is basically divided in two, 
 libraries have to support both, and I think they should have 
 changed more if going to the trouble.


Yes, Python has a real problem with this.

I would like to see a proper deprecation path implemented in D. I 
don't want my code breaking but i'm willing to accept *informed* 
deprecation, followed by removal. Even if this process takes 
place over a few years.
Oct 24 2014