Bill Baxter wrote:

>> Another issue at the moment is GDC support however, and that's a more substantial one in my mind.  Is
>> there a D2 version of GDC yet?
>>> 
> There is code for D2 checked into the GDC repo.
> I don't know how well it works.
> But there has not been a release of a 2.x GDC compiler, no.

To use the D1 version of GDC, one configures it with:

    ./gcc/d/setup-gcc.sh --d-language-version=1
    # currently merged up to DMD 1.022

To instead use the D2 version, one configures it with:

    ./gcc/d/setup-gcc.sh --d-language-version=2
    # currently merged up to DMD 2.005

The D1 language files are in d directories "dmd" and "phobos",
while the new D2 language is in the "dmd2" and "phobos2" dirs.

Support for D 2.0 was added to GDC in revision 160 (Sep, 2007)
But there haven't been any GDC updates in a few months now...


I haven't used it myself yet, just tried DMD 2.x a few times.
(wxD and most samples should be compiling reasonably with D2)

Will probably update my GDC packages with a "gdc2" variant,
that will build the D2 language (while "gdc" would be D1)

--anders

BCS wrote:
> Reply to Bill,
> 
>> Is it really true?  Is there a group of folks who really want D1 to be frozen?
>>
> 
> I'd be open to some changes
> 
>> I myself would like to see D1 get all new features that won't break existing source code.
>>
> 
> but I wouldn't go that far. I think that D1 should at a minimum be highly conservative about adding features. Only feature that have proven very useful in D2 and have become very stable (and are non breaking) and possibly with the restriction that they can be used from older D1 code with little or no updating (cancer const is out)
> 
> 

To pipe in, I am a commercial developer using D1, (project size ~100k) and some non-breaking but enhancing changes to D1 would be very welcome.

I believe I still have a kingdom up for grabs for my personal wishlist:

opIndexConcat
opIndexConcatAssign
+friends

Returning static arrays from functions.

!in (as sugar for (!(a in b)). Ok, this is just a nicety. Still... :) )


Is there even any remote possibility of a D1.1? (Which would not require any changes or break any existing D1 code, but provides some .1 enhancements?).

On Fri, 07 Mar 2008 12:39:03 -0800, Walter Bright wrote:

> I haven't myself gotten const put everywhere it should be in Phobos :)

I can confirm that! I have these little workarounds in my code to cope with an inconsistent Phobos.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Janice Caron Wrote:

> On 07/03/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> >  how many people do you think do use D overall?
> 
> It's not in my nature to form opinions in the absence of data.

That is the funniest, and perhaps most deliberately misleading post ever made to this NG

lmao

Walter Bright Wrote:

> Sean Kelly wrote:
> > == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> >> Sean Kelly wrote:
> >>> but at the moment I'm barred from D2 by the const features,
> >> What exactly is barring you?
> > 
> > The busywork required to adapt Tango to work with D2.  That being mostly the need to add "in" qualifiers to the proper function declarations in tango.stdc and below, as well as tango.sys.win32.  So I'm not really blocked by anything but my own laziness, I suppose. It's a big job and I don't have the time for it at the moment.
> 
> Fair enough. I haven't myself gotten const put everywhere it should be in Phobos :)

The semantics of const are quite different between D1 and D2

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

Saaa wrote:
> "Aarti_pl" <aarti@interia.pl> wrote in message news:fqrsbq$186c$1@digitalmars.com...
>> 2. Semantics of new features in D 2.0 branch can change until 3.0 branch will be crated. It basically means that, when new features will be continuously ported to D 1.0, then 1.0 branch will no more be stable. You will not be able to create any program in D 1.0 (using new features) and be sure that it won't break in future, because this features can be changed later.
> 
> This does not apply. No unstable feature must be allowed to be ported to D1 as it is given that D1 is stable, meaning no new feature may break older code.

D2 is unstable, therefore by definition ANY new feature added to it is also unstable so shouldn't be ported to stable D1. The only guarantee of  a given D2 feature's stability is when the entire D2 branch is locked off and stable and the D3 has begun. Cherry-picking features based on their perceived stability at a given time is dangerous.

"Kris" <foo@bar.com> wrote in message news:fqse2j$2s5n$1@digitalmars.com...
> Janice Caron Wrote:
>
>> On 07/03/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> >  how many people do you think do use D overall?
>>
>> It's not in my nature to form opinions in the absence of data.
>
> That is the funniest, and perhaps most deliberately misleading post ever made to this NG

Now, now!

Brian Hay wrote:
> Saaa wrote:
>> "Aarti_pl" <aarti@interia.pl> wrote in message news:fqrsbq$186c$1@digitalmars.com...
>>> 2. Semantics of new features in D 2.0 branch can change until 3.0 branch will be crated. It basically means that, when new features will be continuously ported to D 1.0, then 1.0 branch will no more be stable. You will not be able to create any program in D 1.0 (using new features) and be sure that it won't break in future, because this features can be changed later.
>>
>> This does not apply. No unstable feature must be allowed to be ported to D1 as it is given that D1 is stable, meaning no new feature may break older code.
> 
> D2 is unstable, therefore by definition ANY new feature added to it is also unstable so shouldn't be ported to stable D1. The only guarantee of  a given D2 feature's stability is when the entire D2 branch is locked off and stable and the D3 has begun. Cherry-picking features based on their perceived stability at a given time is dangerous.

By that definition D2 will never be stable because it has D2 features which are unstable.

Unstable features become stable features over time.  We may disagree on the timing, but, for instance, I doubt there are any serious bugs lurking in D2's implementation of delimited strings (q"(foo)" syntax).

--bb

Sean Kelly wrote:

> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> Sean Kelly wrote:
>> > but at the moment I'm
>> > barred from D2 by the const features,
>> What exactly is barring you?
> 
> The busywork required to adapt Tango to work with D2.  That being mostly
> the need to add "in" qualifiers
> to the proper function declarations in tango.stdc and below, as well as
> tango.sys.win32.  So I'm not really
> blocked by anything but my own laziness, I suppose.  It's a big job and I
> don't have the time for it at the moment.
> 
> 
> Sean

Is that all?  If you give me access I'll guarantee at least 10 hours of my time to add/test that stuff over the next 2-4 days.  I'd request at least some instruction/guidance on how to conform to Tango style and testing requirements.