Top 5

[Sergey Gromov]

Wed, 08 Oct 2008 15:07:27 -0500,
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?

I'd generally like less syntactic freedom in D.  Excessive amounts of 
syntactic sugar cause troubles in many different places.  Economy of 
syntax principle has a flip side: a single mistake can make your program 
mean a whole different thing instead of simply giving you a syntax 
error.  Redundancy is required to detect an error and suggest a fix.

1.  Drop the "array is a slice" idea.  I liked it a lot when I saw the D 
specs but it bit me immediately while I implemented a text parser.  The 
idea sounds nice but it causes too many problems.

There are two major use cases for arrays: building and parsing.  When 
building, you want fast append, you've got a limited number of arrays, 
and you likely don't care if your arrays are a little fat.  When 
parsing, you want data consistency, that is you don't want a sub-array 
to change if you occasionally append to another sub-array.  You also 
want to pass those sub-arrays around a lot and you probably want them to 
be cheap.

An array should be a fat object optimized for fast appending.  It should 
be a class, because you want to pass it into functions and store 
references to it while keeping it a distinct object.  Call it Array!(T) 
or List or Vector or whatever.  It should be implicitly convertable to a 
slice type T[] which can stay what it is now.  It should be built-in 
because array new, .dup and slice ~ should return a new array instance.

It'll probably break lots of generic code.

2.  Drop the "call a function however you want" idea.  Simple property 
method syntax is nice, but excessive freedom is not.  Adding one simple 
keyword fixes the situation.  See
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=13471
for an explanation.

It'll probably break lots of regular code.

3.  Same concern but little experience.  Never bit me personally.  But 
probably the delegate literal syntax should be dropped in favour of a 
dedicated, distinct lambda expression syntax.

4.  Fix the const system.  It scares people.  It scared me off D2 for a 
while even though I liked D2 and I liked the *idea* of a const system.  
There are two items on my wish-list:

a) const-transparent and const-inheriting methods, so that you don't 
have to write the same method thrice as you do in C++ to grant const-
correctness:

class A {
  Object o;
  constof!(o)(Object) get() { return o; }
}
invariant(A) a;
typeof(a.get()); // invariant(Object)

b) unique return values that can be cast to any of mutable, const and 
invariant.  The proposal is to have a "unique" keyword and a unique 
constness type.  Only rvalue can be unique.  Unique can be returned.  
Unique casts implicitly to any other constness type.  Nothing implicitly 
casts to unique.  You can explicitly cast to unique.  New, malloc, 
.deepdup return unique. .dup returns unique if hasNoPointers.