Bill Baxter wrote:
> Porting proven, non-breaking D2.0 features to D1.0 would *not* mutate D1.0 into D2.0.  Const stuff would never be ported to D1.0, for instance because there's really no way to do it without breaking existing D1 code.  And since we're talking about porting proven, backwards-compatible features, it still means D1.0 is significantly more stable than D2.

I agree and would like to see the choice for not moving proven, backwards-compatible features from the D2-playground into D1-stable reconsidered. The big, conceptual changes like const/invariant, pure, shared, closures, ... could not be moved to D1 without breaking existing code, but a lot of small things could.

There should be much less complaints about getting new features every month if these features are fully backwards-compatibly and have been tested in D2 for a while. This is particularly true for things like the partial IFTI improvements that could be considered bugs in D1.

I think some fixes to D1 bugs will prove to be much more troublesome. We recently applied the patch to 313/314 in LDC and that *did* break some existing code (by exposing bugs, but still...).

Walter Bright wrote:
> u wrote:
>> I like this feature so much.
>> Is it possible to back port opDot to D 1.0?
> 
> 
> The problem is for every last feature in D 2.0, there's someone who wants that and only that ported to 1.0. If I moved over opDot, what am I going to say to everyone else? I move over their features too, and then D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.

I think that some consideration should be given to those features which make it easier to migrate code from D1 to D2. Especially things which make version(D2) {...} impossible in D1 code.

Bill Baxter wrote:
> I recall a wise man who once said you shouldn't give much weight to
> what people use as excuses for not using your language.  They probably
> aren't going to use it anyway.

The people using it wanted a stable version.

On Sat, 11 Oct 2008 21:42:27 +0200, Walter Bright <newshound1@digitalmars.com> wrote:

> Bill Baxter wrote:
>> I recall a wise man who once said you shouldn't give much weight to
>> what people use as excuses for not using your language.  They probably
>> aren't going to use it anyway.
>
> The people using it wanted a stable version.


I got an idea, what if you backported some stuff from D2 to D1 (obviously not the const system) and made those features only available when a switch on the command-line was turned on, for example -v1.1? Ought to satisfy both camps, the conservatives and the reformers. Whaddaya say?

Aziz K. wrote:
> I got an idea, what if you backported some stuff from D2 to D1 (obviously not the const system) and made those features only available when a switch on the command-line was turned on, for example -v1.1? Ought to satisfy both camps, the conservatives and the reformers. Whaddaya say?

I've dealt with that on C/C++ compilers for years, and it's an unending testing and configuration nuisance.

On Sun, Oct 12, 2008 at 10:56 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Aziz K. wrote:
>>
>> I got an idea, what if you backported some stuff from D2 to D1 (obviously not the const system) and made those features only available when a switch on the command-line was turned on, for example -v1.1? Ought to satisfy both camps, the conservatives and the reformers. Whaddaya say?
>
> I've dealt with that on C/C++ compilers for years, and it's an unending testing and configuration nuisance.

Python's strategy of introducing new features is the best I've seen by far. And with that they have made big changes in the language without ever creating any major split in the user base, as far as I can tell.

--bb

Bill Baxter wrote:
> Python's strategy of introducing new features is the best I've seen by far.
> And with that they have made big changes in the language without ever
> creating any major split in the user base, as far as I can tell.

Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).

On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Python's strategy of introducing new features is the best I've seen by
>> far.
>> And with that they have made big changes in the language without ever
>> creating any major split in the user base, as far as I can tell.
>
> Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).

Then address the issues of stack vs. heap delegates.

Jarrett Billingsley wrote:
> On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> Python's strategy of introducing new features is the best I've seen by
>>> far.
>>> And with that they have made big changes in the language without ever
>>> creating any major split in the user base, as far as I can tell.
>> Most of the split in the user base is a result of Tango being D1 only (which
>> I hope will be resolved shortly).
> 
> Then address the issues of stack vs. heap delegates.

That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.

Christopher Wright schrieb:
> Jarrett Billingsley wrote:
>> Then address the issues of stack vs. heap delegates.
> 
> That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.

I disagree here.
If you use lambdas for filters in inner loops, that is a main
performance hit. It is more than just "optimization", it is a reason to
change the design. It is a reason not to use D2. It is a D2 show-stopper.
Even worse, no error message is showing you the problematic places, D2
just makes your heap explode.

int findMyTypeXYZ( MyType[] a, int criteria ){
	int match = convCrit( criteria );
	return tango.core.Array.findIf( a, delegate bool(T e){ return e.attrib
is match; });
}

First this run without allocation, now it does allocate.
Image how this behave if called very often :(
And even worse, there is no way to manually delete the allocated stack
frames. So there is no way around the GC runs.
Finally I would end up in rewriting that code, not using a delegate
based design. But IMHO this is one of the important D features.