Top 5

[downs]

Andrei Alexandrescu wrote:
> downs wrote:
>> Andrei Alexandrescu wrote:
>>> Ok, per Aarti's suggestion: without speaking officially for Walter,
>>> let me ask this - what do you think are the top issues you'd like
>>> to see fixed in D?
>>>
>>> Andrei
>>
>> Let me throw in mine as well.
>>
>> As per request, I won't list enhancements, only things I perceive to
>> be issues with D as it _currently_ is.
>>

Oh my god somebody important answered. I'm really calm right now and I'm hoping to finish writing this response before the wave of excitement hits.

>> 1) the Phobos/Tango schism.
> 
> Consider it done.
> 

You have my gratitude.

>> 2) CTFE leaks. (been bitten by this recently)
> 
> Yah.
> 

Good to know I'm not the only one.

>> 3) the Exception/Error problem (they're different things, they
>> shouldn't inherit!)
> 
> I think Exception should inherit Error.
> 

I agree. Certainly a step up from Error inheriting Exception! :)

>> 4) std.zip
> 
> Haven't gotten around to it, but I promise I will. I also have a tar
> file reader hanging around my code somewhere, but I'd first need to work
> on an extensible archive interface first.
> 
>> 5) contracts under inheritance.
> 
> Go on...
> 

Basically, contracts imply that a method "promises" to behave in a certain way.

Thus, any subclasses' methods (the public ones at least) should relax the in { } of the "parent" method, and strengthen the out { }, in a logical extension of covariance and contravariance.

The first of those works. The second, however, does not.

Here's some code that demonstrates the problem.

class A {
	int test()
		out(result) { assert(result < 10); }
		body { return 8; }
}
class B : A {
	override int test() { return 15; }
}

import std.stdio;

void main() {
	A a = new B;
	writefln(a.test()); // violates contract, but does not fail.
}

>> Feature improvements would be:
>>
>> 1) AST manipulation at compile-time (this might supercede and
>> deprecate templates _and_ CTFE by merging them into a common
>> component) 2) auto return type 3) reference types 4) tuple syntax 5)
>> trailing delegates.
> 
> I think this won't come around before D3.
> 

I wouldn't expect it any earlier.

>> Of course, all of these have been brought up before (and mostly
>> ignored), so I don't hold much hope.
> 
> I understand.
> 
> 
> Andrei

Thank you for taking the time to read the original post, and your response.

 --downs