Just a few days ago, Walter was talking about 'the final feature'. Andrei is going through the tedious and unpleasant process of finalizing TDPL with his publisher. In a minute it will be March, so to get anything finalized by the summer of 2010 is already looking like a stretch.

Now we have a whole new slew of suggestions for change.

I think that at some point the membership of digitalmars.D needs to accept that there is a deadline, and that further discussion of the ideal language refers to D3.

Another provocative way of thinking about this is that D2 is already 'E', unless the faithful users of D1 and Tango are to be unceremoniously dumped. In that case, the discussions that have suddenly flared up now are about 'F'.

Time to choose. Will D ever be a widely used programming language, or is it just a excellent vehicle for discussion of programming language features?

Steve

Steve Teale wrote:
> Just a few days ago, Walter was talking about 'the final feature'. Andrei is going through the tedious and unpleasant process of finalizing TDPL with his publisher. In a minute it will be March, so to get anything finalized by the summer of 2010 is already looking like a stretch.
> 
> Now we have a whole new slew of suggestions for change.
> 
> I think that at some point the membership of digitalmars.D needs to accept that there is a deadline, and that further discussion of the ideal language refers to D3.
> 
> Another provocative way of thinking about this is that D2 is already 'E', unless the faithful users of D1 and Tango are to be unceremoniously dumped. In that case, the discussions that have suddenly flared up now are about 'F'.
> 
> Time to choose. Will D ever be a widely used programming language, or is it just a excellent vehicle for discussion of programming language features?
> 
> Steve

assert(cat !in bag);

D2 has officially been frozen. There is no major breaking change we can make at this moment. Defining features that don't change the semantics of existing code is possible, but will be undocumented at least in the first print of TDPL.


Andrei

Andrei Alexandrescu:
> D2 has officially been frozen.

Congratulations to Walter and you then :-)


> There is no major breaking change we can make at this moment. Defining features that don't change the semantics of existing code is possible, but will be undocumented at least in the first print of TDPL.

There is a certain amount of features already partially implemented or partially broken than can be fixed and finished from now on.
A little example: I think this doesn't compile yet (the compiler can't find std.math.sqrt):

void main() {
    double x = 5 ^^ 0.5;
}

Bye,
bearophile

bearophile wrote:
> Andrei Alexandrescu:
>> D2 has officially been frozen.
> 
> Congratulations to Walter and you then :-)

Thanks much.

>> There is no major breaking change we can make at this moment. Defining features that don't change the semantics of existing code is possible, but will be undocumented at least in the first print of TDPL.
> 
> There is a certain amount of features already partially implemented or partially broken than can be fixed and finished from now on.
> A little example: I think this doesn't compile yet (the compiler can't find std.math.sqrt):
> 
> void main() {
>     double x = 5 ^^ 0.5;
> }

Please bugzillize.

Generally this is the time to align the implementation with the book and also to put it in great shape. Walter and I needed to make a lot of microdecisions in the past weeks, which put pressure on the implementation. But I am happy to report that it generally feels that we're turning the right corners.

Regarding the recent debate regarding signed and unsigned numbers, I have great faith in value range propagation.


Andrei

Recently I think Walter has said something about this, but then he was probably too much busy: I'd like to read an article written by Walter that contains a list of the things that D2 does wrong. (Among then I'd like to put that default storage type is mutable instead of immutable, as I have written in a recent post).

Such list can be divided in parts:
1) Some quite important missing things, that can be added later, in D2+ or D3.
2) Errors that somehow can be fixed, if necessary deprecating a feature that we'll just stop using, so we'll use another feature that replaces it.
3) Little or larger errors that are not easy to fix in future, design mistakes that we'll have to live with.

This list is useful for future D2 users to know how to use the language better, for future designers of similar languages, and of course people here will try to invent ways to move some items from the third list to the second list in D3 :-)

Bye,
bearophile

retard Wrote:

> That sounds like heresy :) Would anyone in D community really switch to some other language? I'm sure there's a strong emotional bond already. Even badly designed features and bugs can be seen as a strength if your opinion is heavily biased. Learning a language is an investment. If you've invested lot of time and effort in a language, all kinds of feelings such as bitterness and frustation come up.
> 

Its time to dump C-like languages - I have the evidence.

http://www.modulaware.com/mdlt28.htm

On 2010-02-18 12:18:47 -0500, Martin Franklin <martin246564@btinternet.com> said:

> Its time to dump C-like languages - I have the evidence.
> 
> http://www.modulaware.com/mdlt28.htm

Nice read... and it gives me a new feature idea for D! The article rants about default parameters not being very useful when you have more than one (something I agree with), then propose an improvement:

> Furthermore, they do not provide a great deal of convenience. If a routine has five parameters, the last three of which are optional, and caller wants to assume the defaults for parameters 3 and 4, but must specify parameter 5, then all five parameters must be specified. A better scheme would be to have a default keyword in function calls:
> 
> f (a, b, default, default, e);

Would't that be nice to be able to use the 'default' keyword when you want to use the default value for a parameter? Should be pretty trivial to implement.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:

> Would't that be nice to be able to use the 'default' keyword when you want to use the default value for a parameter? Should be pretty trivial to implement.

Except that to some extent, that would defeat the purpose of default parameters. Part of the idea is that you don't have to worry about their existence unless you actually want to change them. If you're going to have to put the word default there, then in many cases, you might as well just put an actual value yourself.

The one thing that word default would give you would be the ability to choose the the default value for parameters in the middle of the parameter list and still give values for parameters at the end. But that's just extra complication and likely wouldn't be worth the benefit.

- Jonathan M Davis

On 2010-02-18 16:11:39 -0500, Jonathan M Davis <jmdavisProg@gmail.com> said:

> Michel Fortin wrote:
> 
>> Would't that be nice to be able to use the 'default' keyword when you
>> want to use the default value for a parameter? Should be pretty trivial
>> to implement.
> 
> Except that to some extent, that would defeat the purpose of default
> parameters. Part of the idea is that you don't have to worry about their
> existence unless you actually want to change them. If you're going to have
> to put the word default there, then in many cases, you might as well just
> put an actual value yourself.
> 
> The one thing that word default would give you would be the ability to
> choose the the default value for parameters in the middle of the parameter
> list and still give values for parameters at the end. But that's just extra
> complication and likely wouldn't be worth the benefit.

I don't see the complication you talk about. It's no complication unless you use it, and if you feel the need to use it it's probably because there's a benefit. You can still call functions with default parameters by omitting the parameters if you want, I'm not trying to change that.

	void test(int a = 1, int b = 2);

	test();                 // same as test(1, 2);
	test(8);                // same as test(8, 2);
	test(default, 8);       // same as test(1, 8); <- here it's useful


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2010-02-18 22.11, Jonathan M Davis wrote:
> Michel Fortin wrote:
>
>> Would't that be nice to be able to use the 'default' keyword when you
>> want to use the default value for a parameter? Should be pretty trivial
>> to implement.
>
> Except that to some extent, that would defeat the purpose of default
> parameters. Part of the idea is that you don't have to worry about their
> existence unless you actually want to change them. If you're going to have
> to put the word default there, then in many cases, you might as well just
> put an actual value yourself.
>
> The one thing that word default would give you would be the ability to
> choose the the default value for parameters in the middle of the parameter
> list and still give values for parameters at the end. But that's just extra
> complication and likely wouldn't be worth the benefit.
>
> - Jonathan M Davis

That sounds like named parameters, which could be nice to have.