bearophile wrote:
> BCS:
>> A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give.
> 
> D2 has enough warts now, so it's much better to not add some more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.

I think in this case, it's more about cleaning up and polishing, than adding "warts".

The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.

> Bye,
> bearophile

grauzone Wrote:

> bearophile wrote:
> > BCS:
> >> A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give.
> > 
> > D2 has enough warts now, so it's much better to not add some more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.
> 
> I think in this case, it's more about cleaning up and polishing, than adding "warts".
> 
> The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.

So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze.

It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.

BCS wrote:

> Hello justme,
> 
>> bearophile Wrote:
>> 
>>> C# will probably not follow the route of stagnation of Java for some more time, thanks to Mono too. I don't like that string interpolation syntax because it looks unsafe, and that design of tuples can be improved, but they are listening to programmes (even if they risk creating a mudball language):
>>> 
>>> http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
>>> 
>>> More on those tuples:
>>> http://tirania.org/blog/archive/2009/Dec-23.html
>>> Eventually it will be quite useful to have some very well designed
>>> multi-return support in D (like those tuples, but better).
>>> 
>> Doesn't D2 already have tuples in Phobos. D has the comma operator which C# doesn't so such syntax is not possible in D, me thinks.
>> 
> 
> A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give.
> 
> int i = 1, j = 2;
> 
> (i, j) = (j, i); // swap
> 
> i = (j+= i, i*2 + j); // first expression gets evaluated and dropped.
> 
> Thoughts?

I have had the same idea and thinking about it I have not found any problems with it. So I would get hapy if it was implementet. When tupples where first introduced in D the ovious problems with them was the auto flattening and lack of literal syntax, fixing that would probably make using tuoples much nicer. (Allowing things like multiple return value as used in matlab)

On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme@somewhere.net> wrote:

> grauzone Wrote:
>
>> bearophile wrote:
>> > BCS:
>> >> A though on the comma operator: if the comma operator were defined  
>> to give
>> >> a tuple type and be implicitly castable to any suffix of it's self,  
>> then
>> >> you could get both the comma expression usage that Walter wants as  
>> well as
>> >> all the fun things that tuple expressions give.
>> >
>> > D2 has enough warts now, so it's much better to not add some more.  
>> Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.
>>
>> I think in this case, it's more about cleaning up and polishing, than
>> adding "warts".
>>
>> The big danger is, that this may require incompatible language changes,
>> which won't be possible anymore after D2. D3? Anyone who talks about D3
>> must be kidding.
>
> So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze.
>
> It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.


According to development stages you provided, D2 is currently in alpha/beta period. Feature freeze will follow once TDPL is released (around March, 2010). Stabilization and release is even further, and D3 is sooo far away it's hardly imagineable we will see any signs of it in a foreseeable future :)

Denis Koroskin wrote:
> On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme@somewhere.net> wrote:
> 
>> grauzone Wrote:
>>
>>> bearophile wrote:
>>> > BCS:
>>> >> A though on the comma operator: if the comma operator were defined 
>>> to give
>>> >> a tuple type and be implicitly castable to any suffix of it's 
>>> self, then
>>> >> you could get both the comma expression usage that Walter wants as 
>>> well as
>>> >> all the fun things that tuple expressions give.
>>> >
>>> > D2 has enough warts now, so it's much better to not add some more. 
>>> Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.
>>>
>>> I think in this case, it's more about cleaning up and polishing, than
>>> adding "warts".
>>>
>>> The big danger is, that this may require incompatible language changes,
>>> which won't be possible anymore after D2. D3? Anyone who talks about D3
>>> must be kidding.
>>
>> So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze.
>>
>> It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.
> 
> 
> According to development stages you provided, D2 is currently in alpha/beta period. Feature freeze will follow once TDPL is released (around March, 2010). Stabilization and release is even further, and D3 is sooo far away it's hardly imagineable we will see any signs of it in a foreseeable future :)

Yes, that's about right.  Let's get an estimate about stablisation:

There are 1400 open bugs (DMD+Phobos), which are currently being fixed at the rate of 50/month.
Historically, new bugs have been found at the rate of 66/month.
Since D2 began, 50% of the open bugs have been D2-only. So, 50% of the bugs have been related to new features.
Which would suggest that even if the bug rate halves when after the feature freeze, it'll be about 5 years until the bug count drops to zero... :-(
Actually, I don't think it's that bad, since some of the most important structural compiler bugs have been fixed, which should greatly reduce the rate that new bugs are found.
Even so, I'd recommend at least two years of bug-fixes and library development (and toolchain issues), before we even think about more features.

Don:
> I'd recommend at least two years of bug-fixes and library development (and toolchain issues), before we even think about more features.

There are two other important thing that can be done in that stabilizing period:
1) find where are the D2 design mistakes and invent better ways to design the same features.
2) Invent new ways to use D2 language (this has happened too all major languages, for example the introduction of the many lazy features of Python3 doesn't come after design of Python2, it comes from the slow invention of new ways to use Python, partially invented by R. Hettinger. Later some of such ideas are being moved from the std library (itertools) to the language itself (the built-in map and filter become lazy, etc)).

Bye,
bearophile

On 12/30/2009 12:38 AM, BCS wrote:
> Hello grauzone,
>> Why not make the programmer write tuple[$-1] instead?
>>
>> i = (j += i, i*2 + j)[$-1];
>>
>> There's no reason to keep the current comma operator.
> 
> Frankly, while I have no problem with it, I'd also be fine with dumping the comma operator all together, even making the [$-1] thing illegal ("code has no effect" and all that) but Walter has time and again shot down anything that does away with the comma operator so I was looking at it as a way to have my cake and eat it to.

Can the comma operator be given a different symbol to use?  How about, e.g., a double comma:

auto i = 1, 2;	// tuple
auto j = 1,,2;	// sequence operator

—Joel

Wed, 30 Dec 2009 21:30:14 -0500, Joel C. Salomon wrote:

> On 12/30/2009 12:38 AM, BCS wrote:
>> Hello grauzone,
>>> Why not make the programmer write tuple[$-1] instead?
>>>
>>> i = (j += i, i*2 + j)[$-1];
>>>
>>> There's no reason to keep the current comma operator.
>> 
>> Frankly, while I have no problem with it, I'd also be fine with dumping the comma operator all together, even making the [$-1] thing illegal ("code has no effect" and all that) but Walter has time and again shot down anything that does away with the comma operator so I was looking at it as a way to have my cake and eat it to.
> 
> Can the comma operator be given a different symbol to use?  How about, e.g., a double comma:
> 
> auto i = 1, 2;	// tuple
> auto j = 1,,2;	// sequence operator

Wouldn't that break the C compatibility?

justme wrote:
> grauzone Wrote:
> 
>> bearophile wrote:
>>> BCS:
>>>> A though on the comma operator: if the comma operator were
>>>> defined to give a tuple type and be implicitly castable to any
>>>> suffix of it's self, then you could get both the comma
>>>> expression usage that Walter wants as well as all the fun
>>>> things that tuple expressions give.
>>> D2 has enough warts now, so it's much better to not add some
>>> more. Languages must be tidy, when possible. It's often better to
>>> not have a feature that having a dirty one.
>> I think in this case, it's more about cleaning up and polishing,
>> than adding "warts".
>> 
>> The big danger is, that this may require incompatible language
>> changes, which won't be possible anymore after D2. D3? Anyone who
>> talks about D3 must be kidding.

On the other hand, one could introduce "fixed tuples" as a new feature, that doesn't touch the old tuples. It would be annoying, but allows for perfect backwards compatibility.

> So D3 won't ever appear? At least in many open source projects the
> final released is tagged one to two weeks before the final release.
> Distributions have then time to repackage the release. Meanwhile, the
> core developers are already enthusiastically implementing wild new
> features after a long feature freeze.

D3 would just mean "incompatible to D2". The "final" version of D1 (dmd 1.000) was released on Jan 2, 2007, and the first version of D2 (dmd 2.000) on Jun 17, 2007. Can't let that happen again.

But adding features after finalization in a backward compatible way would be nice. Other languages can do it too, why not D?

> It's similar kind of tick-tock as Intel has with their CPU line (1
> smaller process -> 2 improved core -> goto 1). In successful software
> projects they have alpha/beta period, feature freeze, stabilization
> period, release, new alpha/beta period etc. Concurrently new bugfix
> releases come out just like with D. I haven't heard of new features
> lately so D2 must be stabilizing now.

That isn't the case. Have a look at the "New/Changed Features" section in the changelog: http://www.digitalmars.com/d/2.0/changelog.html