Sean Kelly wrote:
> What worries me is that long
> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.

Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.

Robert Fraser wrote:
> Sean Kelly wrote:
>> What worries me is that long
>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
> 
> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.

A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.

Chris Wright wrote:
> Robert Fraser wrote:
>> Sean Kelly wrote:
>>> What worries me is that long
>>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
>>
>> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.
> 
> A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.

When you say "nobody" are you suggesting that the D community should create a 1.1 branch and release it whether Walter wants it or not?

--bb

Bill Baxter wrote:
> Chris Wright wrote:
>> Robert Fraser wrote:
>>> Sean Kelly wrote:
>>>> What worries me is that long
>>>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
>>>
>>> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.
>>
>> A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.
> 
> When you say "nobody" are you suggesting that the D community should create a 1.1 branch and release it whether Walter wants it or not?
> 
> --bb

That's a good idea (I don't think Walter would be against it; but he certainly doesn't have the time to maintain 3 branches). I suspect it would be of GDC, though; since DMD's backend is closed-source.

Bill Baxter wrote:
> Chris Wright wrote:
>> Robert Fraser wrote:
>>> Sean Kelly wrote:
>>>> What worries me is that long
>>>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
>>>
>>> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.
>>
>> A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.
> 
> When you say "nobody" are you suggesting that the D community should create a 1.1 branch and release it whether Walter wants it or not?

I am. There seems to be demand for it. And if there were such a branch, Walter could even stop maintaining the 1.x branch because bugfixes from the 2.x branch would get ported to the 1.1 branch.

This isn't ideal for the community, perhaps. If enough people were involved, however, Walter would just be working on an experimental branch, and the community would handle bugfixes.

> --bb

Chris Wright wrote:
> 
> I am. There seems to be demand for it. And if there were such a branch, Walter could even stop maintaining the 1.x branch because bugfixes from the 2.x branch would get ported to the 1.1 branch.
> 
> This isn't ideal for the community, perhaps. If enough people were involved, however, Walter would just be working on an experimental branch, and the community would handle bugfixes.
> 
>> --bb

imho, this would only be a good idea if 1.1 would not be another branch, but replace the current D1 language. D1 was and is about D not being a moving target and that has been pretty successful as far as I can see. Creating a language incompatible with both 1.0x and 2.x will only complicate matters.

Implementing 'changes' like the currently discussed one that don't have much impact or are actually clarifications from the spec is one thing. But adding new features, even if backward compatible, may introduce again the situation that libraries grow out-of-sync. How much of a problem that will be in practice, I don't know. But development in D is much more practical now than before D1 was stabilized, and it would be very unfortunate to lose that.

Besides, the plan is stabilize D2 somewhere this year already (iirc). Thus such a branch might not even be worthwhile before the migration starts.

Lutger wrote:
> Implementing 'changes' like the currently discussed one that don't have much
> impact or are actually clarifications from the spec is one thing. But
> adding new features, even if backward compatible, may introduce again the
> situation that libraries grow out-of-sync.

I'd hope the features selected would be such that most D libraries would still be able to compile. For example, Java is _mostly_ backwards compatible to 1.0 (if you take out the "enum" and "assert" keywords, it;s likely that 1.0 code would compile fine under 1.6). I'd hope the same is true of D if it gets a 1.1 branch (that is, if any new features are added, they are done in a way that DOES not keep libraries out-of-sync).

If it was designed in a way to keep a large, mostly-spanning subset of (multiple versions of) D1 libraries/apps (i.e. Tango, Phobos, DFL, DWT, Derelict, MiniD, a few other big ones) compiling at every release, it would be reasonable to assume that most D1 code would compile rather easily with it. I'd also hope that any DStress tests that pass with D 1.030 (or whenever the branch is made) would remain a strict subset of the DStress tests that pass as the branch evolves.

If these conditions were met, it would be possible to add in *some* backwards-compatible changes that would benefit the community and still allow libraries designed for the 1.0 branch to keep compiling. But that's just my personal pipe dream: I'm sure some people wouldn't mind having 3 completely distinct branches, while others would prefer that only bugfixies make it into 1.1.

Robert Fraser wrote:
> Lutger wrote:
>> Implementing 'changes' like the currently discussed one that don't have much
>> impact or are actually clarifications from the spec is one thing. But
>> adding new features, even if backward compatible, may introduce again the
>> situation that libraries grow out-of-sync.
> 
> I'd hope the features selected would be such that most D libraries would still be able to compile. For example, Java is _mostly_ backwards compatible to 1.0 (if you take out the "enum" and "assert" keywords, it;s likely that 1.0 code would compile fine under 1.6). I'd hope the same is true of D if it gets a 1.1 branch (that is, if any new features are added, they are done in a way that DOES not keep libraries out-of-sync).

So you'd accept added keywords such as __traits, I take it? Though invariant would be a pretty controversial one to add.

> If it was designed in a way to keep a large, mostly-spanning subset of (multiple versions of) D1 libraries/apps (i.e. Tango, Phobos, DFL, DWT, Derelict, MiniD, a few other big ones) compiling at every release, it would be reasonable to assume that most D1 code would compile rather easily with it. I'd also hope that any DStress tests that pass with D 1.030 (or whenever the branch is made) would remain a strict subset of the DStress tests that pass as the branch evolves.
> 
> If these conditions were met, it would be possible to add in *some* backwards-compatible changes that would benefit the community and still allow libraries designed for the 1.0 branch to keep compiling. But that's just my personal pipe dream: I'm sure some people wouldn't mind having 3 completely distinct branches, while others would prefer that only bugfixies make it into 1.1.

I think a fair number of people would be perfectly happy with a D2 branch minus const. I mean, what else was added that's not to love? Besides instability, that is. But the only thing preventing people from using most of these libraries with dmd2.014 is probably const.

Chris Wright wrote:
> Bill Baxter wrote:
>> Chris Wright wrote:
>>> Robert Fraser wrote:
>>>> Sean Kelly wrote:
>>>>> What worries me is that long
>>>>> asked-for bug fixes like this may be left out of DMD 1.0 as a way to "encourage" people to move to D 2.0.  If that happens, I'm out.
>>>>
>>>> Indeed that's a fear I have as well. D 1.0 has never been fully stable (look at the ".init" change that happened after 2.0 was out... that broke a lot of code). So it seems rather arbitrary that a bug fix like this (reported as bug, not an enhancement, before 2.0 was on the horizon) would only make it to the 2.0 branch.
>>>
>>> A lot of people have been annoyed by a lot of these changes. Unfortunately, nobody (and that includes the lack of me) has gotten off their butts to release a DMD 1.1.x branch.
>>
>> When you say "nobody" are you suggesting that the D community should create a 1.1 branch and release it whether Walter wants it or not?
> 
> I am. There seems to be demand for it. And if there were such a branch, Walter could even stop maintaining the 1.x branch because bugfixes from the 2.x branch would get ported to the 1.1 branch.

Though this is made harder since the DMD frontend isn't developed using any version control system that I can access. So I can only see a whole lump of changes between two dmd2 revisions, many of which are bugfixes, many of which are changed features that will impact user code, and some of which are actually nonbreaking features. Given the overhauls done to const, it may be a better idea just to diff dmd1.030 and dmd2.014 and start from there.

Chris Wright wrote:
> So you'd accept added keywords such as __traits, I take it? Though invariant would be a pretty controversial one to add.

Well, __traits is okay because it isn't commonly used as an identifier. But I'd prefer "macro" be changed to something like "__macro" in a backport (people might be using that as a variable name). Again, just personal opinion, that stuff doesn't matter too much.

> I think a fair number of people would be perfectly happy with a D2 branch minus const. I mean, what else was added that's not to love? Besides instability, that is. But the only thing preventing people from using most of these libraries with dmd2.014 is probably const.

IMO, pure and nothrow, too. I think it's a good idea but it requires too much library support (i.e. there's no way to write a standard lib that would work well under D1.0 and D1.1 if the latter had pure and nothrow). Also, overload sets (great idea, but very much breaking).

I think there's at least one naysayer for every D2 feature, so you can't please everybody. I think whoever creates the branch needs to go mini-Walter and decide for him/her self which features to back port -- the D community will be richer with it than without it.