Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.

Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?

I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.

So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.

Is it really true?  Is there a group of folks who really want D1 to be frozen?

I myself would like to see D1 get all new features that won't break existing source code.

Things like:
* New string literals
  - q{a=b} D-token string syntax,
  - delimited strings, q"(...)"
  - heredocs, q"EOF...
* IFTI that works even if you specify one parameter,
* Enhanced is expression
  - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
  - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
* foreach(i; 0..10) syntax (ForeachRangeLiteral)
* Overload sets


I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.

I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.

--bb,
(who has now written and/or ported about 200,000 lines of D according to a quick check with 'wc')

Bill Baxter wrote:

> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
> 
> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
> 
> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
> 
> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
> 
> Is it really true?  Is there a group of folks who really want D1 to be frozen?
> 
> I myself would like to see D1 get all new features that won't break existing source code.
> 
> Things like:
> * New string literals
>    - q{a=b} D-token string syntax,
>    - delimited strings, q"(...)"
>    - heredocs, q"EOF...
> * IFTI that works even if you specify one parameter,
> * Enhanced is expression
>    - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
>    - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
> * foreach(i; 0..10) syntax (ForeachRangeLiteral)
> * Overload sets
> 
> 
> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
> 
> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.
> 
> --bb,
> (who has now written and/or ported about 200,000 lines of D according to
> a quick check with 'wc')


I'm a D 1.x user who's ready to try D 2.x.  My only problem is that I use Tango, so I wait patiently.  I'm ok with D 1.x being very stable and only including fixes of obvious bugs.  Should there be something between a very stable 1.0xxx and 2.x?  Maybe.  I guess the question is how much stability is desired?  Why not move to 2.x now that const is stable?

--jason
(who has now written and/or ported about 9,000 lines of D according to a
quick check with 'wc')

Jason House wrote:
> Bill Baxter wrote:

> I'm a D 1.x user who's ready to try D 2.x.  My only problem is that I use
> Tango, so I wait patiently.  I'm ok with D 1.x being very stable and only
> including fixes of obvious bugs.  Should there be something between a very
> stable 1.0xxx and 2.x?  Maybe.  I guess the question is how much stability
> is desired?  Why not move to 2.x now that const is stable?

A) I've got 200,000 lines to port in order to move to D2.x

B) I'm pretty unenthusiastic about const now.

C) I want _some_ stability.  Breaking changes can be introduced into 2.x at any time.  And I think it's best that way.  Walter should feel completely free to break anything he sees fit to break in the D2 tree.


--bb

Bill Baxter wrote:
> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
> 
> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
> 
> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
> 
> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
> 
> Is it really true?  Is there a group of folks who really want D1 to be frozen?
> 
> I myself would like to see D1 get all new features that won't break existing source code.
> 
> Things like:
> * New string literals
>   - q{a=b} D-token string syntax,
>   - delimited strings, q"(...)"
>   - heredocs, q"EOF...
> * IFTI that works even if you specify one parameter,
> * Enhanced is expression
>   - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
>   - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
> * foreach(i; 0..10) syntax (ForeachRangeLiteral)
> * Overload sets
> 
> 
> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
> 
> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.
> 
> --bb,
> (who has now written and/or ported about 200,000 lines of D according to a quick check with 'wc')

Having an unstable base (and I don't mean unstable in the software sense) makes reimplementations (including partial reimplementations e.g. GDC), ports, etc very difficult. With a feature freeze on 1.0, there is a solid, specified language that one can target without having to keep up with a changing specification.

 - Gregor Richards

On Thu, 06 Mar 2008 21:43:51 -0500, Jason House wrote:

> Bill Baxter wrote:
> 
>> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
>> 
>> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
>> 
>> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
>> 
>> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
>> 
>> Is it really true?  Is there a group of folks who really want D1 to be frozen?
>> 
>> I myself would like to see D1 get all new features that won't break existing source code.
>> 
>> Things like:
>> * New string literals
>>    - q{a=b} D-token string syntax,
>>    - delimited strings, q"(...)"
>>    - heredocs, q"EOF...
>> * IFTI that works even if you specify one parameter, * Enhanced is
>> expression
>>    - is ( Type Identifier : TypeSpecialization , TemplateParameterList
>>    ) - is ( Type Identifier == TypeSpecialization ,
>>    TemplateParameterList )
>> * foreach(i; 0..10) syntax (ForeachRangeLiteral) * Overload sets
>> 
>> 
>> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
>> 
>> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.
>> 
>> --bb,
>> (who has now written and/or ported about 200,000 lines of D according
>> to a quick check with 'wc')
> 
> 
> I'm a D 1.x user who's ready to try D 2.x.  My only problem is that I use Tango, so I wait patiently.  I'm ok with D 1.x being very stable and only including fixes of obvious bugs.  Should there be something between a very stable 1.0xxx and 2.x?  Maybe.  I guess the question is how much stability is desired?  Why not move to 2.x now that const is stable?
> 
> --jason
> (who has now written and/or ported about 9,000 lines of D according to a
> quick check with 'wc')

I'm with Jason and Gregor on this one. Would it be nice to have these changes, yes, but I don't think that is the way to look at it. Even if D3 is completely compatibly with all D2 code, I wouldn't want it be in the D2 tree.

Think about it, you don't get all the Java 7 stuff in Java 6, just because you don't see it to want it. D2 is going to introduce a lot of breaking in old code, and headaches with const that many don't want. And I believe this is really where you're coming from? You like the lack of const, but want the other stuff? (not saying there is anything wrong with it. I'm kinda frightened to switch, eager, but frightened)

On Fri, 07 Mar 2008 11:51:48 +0900, Bill Baxter wrote:

> Jason House wrote:
>> Bill Baxter wrote:
> 
>> I'm a D 1.x user who's ready to try D 2.x.  My only problem is that I use Tango, so I wait patiently.  I'm ok with D 1.x being very stable and only including fixes of obvious bugs.  Should there be something between a very stable 1.0xxx and 2.x?  Maybe.  I guess the question is how much stability is desired?  Why not move to 2.x now that const is stable?
> 
> A) I've got 200,000 lines to port in order to move to D2.x
> 
> B) I'm pretty unenthusiastic about const now.
> 
> C) I want _some_ stability.  Breaking changes can be introduced into 2.x at any time.  And I think it's best that way.  Walter should feel completely free to break anything he sees fit to break in the D2 tree.
> 
> 
> --bb

Is there that much required in moving from D1 to D2?
IMO, The biggest thing (and forced) is strings.
Most of the other things are optional (I guess that will change later when
const pervades the library)

- diboss

(whose ~7000 lines of D code is feeling mighty inadequate to Bill's 200K)

On Fri, 07 Mar 2008 11:20:38 +0900, Bill Baxter wrote:

> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.

I'm probably going against the trend here, but I do not code for D1 any more. My method of working is that I code for D2, then when that is working, I make it work with D1. Sure, it might mean recoding some slabs of code totally differently, but I'm not going to loose sleep if I'm not 100% D1 compatible, as that version WILL definitely be phased out before D2 will.

D2 is fairly stable now in terms of syntax changes even though it has a number of bugs still remaining. But this is not mission-critical stuff I'm relying on right now. I don't think I'd write serious commercial software in D yet, of any flavour.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
7/03/2008 3:38:52 PM

Gregor Richards wrote:
> Bill Baxter wrote:
>> Currently as we all know, D1 gets no new features, and D2 is a crazy rocketship that could change direction at any moment.
>>
>> Now I know a lot of people were asking for D to become more stable pre D1 days, but is this really what you wanted?
>>
>> I had initially assumed that the freeze on D1 was at least as much due to time constraints on Walter as it was due to a desire for stability. But in a recent message Walter said that wasn't the case.  He said that backporting things from D2 to D1 was pretty trivial.
>>
>> So really then, it to comes down to Walter believing that the D community wants D1 to be feature frozen.
>>
>> Is it really true?  Is there a group of folks who really want D1 to be frozen?
>>
>> I myself would like to see D1 get all new features that won't break existing source code.
>>
>> Things like:
>> * New string literals
>>   - q{a=b} D-token string syntax,
>>   - delimited strings, q"(...)"
>>   - heredocs, q"EOF...
>> * IFTI that works even if you specify one parameter,
>> * Enhanced is expression
>>   - is ( Type Identifier : TypeSpecialization , TemplateParameterList )
>>   - is ( Type Identifier == TypeSpecialization , TemplateParameterList )
>> * foreach(i; 0..10) syntax (ForeachRangeLiteral)
>> * Overload sets
>>
>>
>> I'm all with the sentiment that D1 code that compiles today should compile tomorrow.  That kind of stability is great.  But if it's not a big time commitment for Walter (which he says it's not), I see no good reason to keep new backwards-compatible features out of D1.
>>
>> I've heard other folks saying they want this from D1 too, but what I haven't heard is a great swell of active D developers saying that new features would be a detriment to their work.
>>
>> --bb,
>> (who has now written and/or ported about 200,000 lines of D according to a quick check with 'wc')
> 
> Having an unstable base (and I don't mean unstable in the software sense) makes reimplementations (including partial reimplementations e.g. GDC), ports, etc very difficult. With a feature freeze on 1.0, there is a solid, specified language that one can target without having to keep up with a changing specification.
> 
>  - Gregor Richards

People reimplementing D come in two categories:
1) from scratch,
   These people can just stick with whatever fixed 1.x version of the specification they want.  Any bug fixes that Walter makes to the 1.x series wouldn't help them anyway.
2) dmdfe based,
   These people already have to merge with latest dmdfe changes to get the bug fixes, so their lives won't become any more difficult.  Still just a merge from upstream.

Also, given the fact that there really aren't any viable examples of 1) right now that even implement the 1.0 spec, I'm not sure this is a very important category to base decisions upon.  There are many more actual users of D 1.x than there are people implementing D from scratch and there are basically zero users of clean-room implementations of the D 1.x spec.

--bb

Bill Baxter Wrote:
> I myself would like to see D1 get all new features that won't break existing source code.

I'm a newbie here, so take my opinion with a truckload of salt.

Why not make a "backports" version?

Make a D1.5 branch that will patch the stable D1 with non-breaking D2 features, which are already pretty stable.  That way the frozen D1 can stay as stable as possible and encourage more serious use, and the D1.5(or whatever) can be used by the more adventurous of us.

The only downside I see is keeping it in sync with D1 bug fixes.

Ryan

Ryan Bloomfield wrote:
> Bill Baxter Wrote:
>> I myself would like to see D1 get all new features that won't break existing source code.
> 
> I'm a newbie here, so take my opinion with a truckload of salt.  
> 
> Why not make a "backports" version?  
> 
> Make a D1.5 branch that will patch the stable D1 with non-breaking D2 features, which are already pretty stable.  That way the frozen D1 can stay as stable as possible and encourage more serious use, and the D1.5(or whatever) can be used by the more adventurous of us. 
> 
> The only downside I see is keeping it in sync with D1 bug fixes.

That would satisfy me at least, but it almost doubles the number of versions of D someone might be using with DMD vs GDC, Phobos vs Tango, D1 vs D1.5 vs D2.

I think maintaining a whole separate version likely would be a burden for Walter.  There'd need to be another bifurcation of the web pages for instance.

--bb