March 07, 2008
> 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

You mean a D2 without const?

L.
March 07, 2008
Derek Parnell wrote:
> 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.


Probably I should do what you've done and take an honest stab at porting my code to D2 to see how bad it really is.  But if I make the transition, I'm just going to turn my back on D1 completely.  There's no way I'm going to try to maintain compatibility.

What I know about D2 code comes mostly from porting Phobos2 to Phobos1, and frankly the need for bizarre constructs like "assumeUnique" just doesn't sit well with me.  Additionally, after ripping a lot of redundant const iterators out of various C++ ports, I really don't feel like putting them back.  The code is a lot clearer and much less redundant without them.  But I feel the code will now be incomplete without them in D2.

> 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.

At least I know the placement of "const" for methods seems to still be somewhat up in the air.  Does it go before/after/either? Or maybe const(this) anyone?  Updating my code for that one change could be a pretty big headache if I choose the flavor that gets deprecated.

More than that, I *want* Walter to feel like he can break things big time in D2.  It's a great opportunity to improve the basics of the language.

--bb

March 07, 2008
Jesse Phillips wrote:

> 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)

Maybe a better analogy is with Python 3K.  It's a major release with some new breaking additions, and I seem to recall they're planning on having Python 2.x releases that incorporate backported features from Python 3K.  Probably someone here is more up to date on that situation than me.

Anyway I think an analogy with Java -- backed by a behemoth company, now on the 7th major release, with millions of users -- is not really apt. D can be and is more agile than that.

--bb
March 07, 2008
Lionello Lunesu wrote:
>> 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
> 
> You mean a D2 without const?

:-)

Without breaking changes.  For the most part that appears to be const/invariant/enum right now, yes.

I also didn't mention closures because I think maybe they are likely to cause existing D1 programs to behave differently.

I also didn't mention __traits because it seems still in incubation. That's what D2 is perfect for.  Putting features in incubation till they prove stable.

So yeh let me state that I don't think changes to D2 should be backported instantly.  They should get tried out in D2 and survive a few releases before showing up in D1.

--bb
March 07, 2008
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fqq8ps$g0r$1@digitalmars.com...
> 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.

I'd like a lot of the new D2 features (__traits, a lot of the new compile-time stuff like template enhancements, foreach(i; 0 .. 10)) but at the same time I don't feel like DMDFE is mature enough to offer me a stable, bug-free implementation of many of these features.  Furthermore I'm not entirely sold on const and until that _actually_ gets sorted I'd like to stay away from D2.   God only knows how long _that_ will take.  A D1 + extras version of the compiler would be nice but that seems like a special provision that would only make it harder for compiler implementors and library users to conform to.

I'll be contributing to Dil as much as I can over the rest of the semester and the summer break, undoubtedly also contributing to the D2 side of development, but I can't promise that I'll be switching to D2 any time soon. Before D1 came out, I really didn't have a choice as to which version of D to use, but now that D1 has been partially (mostly) stabilized, I'd rather stick to it than to the ever-changing D2.


March 07, 2008
Jesse Phillips wrote:
> 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. 

I also can see problems with having to support even more versions of D if D 1.0 gets semantic changes.
March 07, 2008
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)


March 07, 2008
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote
[snip]
> Furthermore I'm not entirely sold on const and until that _actually_ gets sorted I'd like to stay away from D2.   God only knows how long _that_ will take.  A D1 + extras version of the compiler would be nice but that seems like a special provision that would only make it harder for compiler implementors and library users to conform to.
>
> I'll be contributing to Dil as much as I can over the rest of the semester and the summer break, undoubtedly also contributing to the D2 side of development, but I can't promise that I'll be switching to D2 any time soon. Before D1 came out, I really didn't have a choice as to which version of D to use, but now that D1 has been partially (mostly) stabilized, I'd rather stick to it than to the ever-changing D2.


As one of the early proponents of const (actually, a subset of const), I have to admit to being disappointed with the current D2 mechanisms. Have avoided commentry in the past, because D2 has been positioned as merely experimental. However, from what I understand, Walter is feeling like the const design is almost baked.

My original beef was not being able to protect a return value (such as a char[]) from being abused without having to copy the returned content instead of returning a slice. At the time, the 'in' modifier provided suitable intent and control for read-only parameters, so the /hope/ was for something reasonbly simple (to the user) in order to handle the return-value aspect.

While I understand how things can sometimes quickly become complex while trying to support a simple notion, there's nothing trivial at all about using or comprehending the D2 const mechanisms. A claim has been made that one does not have to use or be aware of const or invariant to use D2 ... unfortunately that does not appear to be the case in practice, and the added complexity makes D2 harder to work with than D1.

At least for now, D1 is the language of choice for me. New features are nice enough, but they're not nearly sufficient to outweight the current const/invariant difficulties.

2c


March 07, 2008
Same here.

stable = non breaking
not stable = will probably be broken

So whatever people might think about the stability of D2, Walter should
never be discouraged to break it(s specs).
I thus welcome every single new non breaking  feature in D1.


March 07, 2008
On Thu, 6 Mar 2008 22:35:24 -0800, Kris wrote:

> the added complexity makes D2 harder to work with than D1.

It took me a while to port Bud over to D2, but that was due mostly to the changing 'char[]' to 'string' and the many .dup calls that were used to protect returned slices. Once I removed all of those, I then had to add back in a handful of .idup calls but now the code is a lot cleaner and little faster.

Just for fun, I spent a couple of hours last night writing a turn-based strategy game, a bit similar to Microsoft's Age of Empires concept, to get some practice in using OO techniques. D2 made things so easy and clean looking. I'm sure D1 would also be nice, but I've nothing (yet) to say against D2's way of seeing the world.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
7/03/2008 6:14:25 PM