Top 5

[Andrei Alexandrescu]

Sergey Gromov wrote:
> 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.

Ok. I guess what you're saying is that the Hamming distance between 
semantically correct notation should be large.

> 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.

I think there are very solid reasons for keeping slices the primitive 
array type of choice. Rock-solid in fact. I will go over them in TDPL, 
but in short pointers are too low-level a primitive for arrays, and more 
than (the equivalent of) a pair of pointers would be too non-primitive.

For appending, I already put Appender in std.array. For parsing, I 
didn't get your argument.

> 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.

This would be an uphill battle with Walter. He'd like to implement the 
property calls to work only for pairs of functions, something discussed 
here before.

> 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.

That needs to be looked at indeed.

> 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)

We definitely must implement what I call qualifier-equivariance.

> 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.

I think Unique is important and can be implemented as a library type 
(after Walter operates a few changes in the way copy construction 
works). More on that later.


Andrei