Who favors the current D1 situation?

Gregor Richards Richards at codu.org
Fri Mar 7 15:09:00 PST 2008


Bill Baxter wrote:
> 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.

We're not talking about bug fixes, we're talking about new features. If 
new features creep into D 1.0, then new code won't work on their 
compilers, and then we get "for D 1.0 (oh but only DMD, not fooDC)" 
messages.

> 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 aren't any != there never will be any. Making D1 a moving target 
just discourages such development.

> There are many more actual 
> users of D 1.x than there are people implementing D from scratch 

Um ... duh?

> and 
> there are basically zero users of clean-room implementations of the D 
> 1.x spec.

And it's a good thing that situations never ever change over time.

> 
> --bb

  - Gregor Richards



More information about the Digitalmars-d mailing list