Top 5

[Christopher Wright]

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

Catenating an array to a slice shouldn't do it in place unless the slice 
includes the end of the original array. If it does, that's a bug.

And parsers generally don't need to modify the input. I'm rather curious 
as to why yours was.

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