Why I (Still) Won't Use D

[Benji Smith]

e-t172 wrote:
> Benji Smith a écrit :
>> I also would have preferred to have growable arrays and associative 
>> arrays in the standard library than in the language.
>>
>>   // Would be ideal. Growable arrays would be best implemented as a
>>   // templatized collection class.
>>   List!(String) words = [ "hello, "world" ];
> 
> Did you read http://www.digitalmars.com/d/2.0/builtin.html ?

Yeah, and while there are some good points to consider there, think 
about this...

The d language includes 3 different kinds of containers:

* Fixed-size immutable lists of immutable values (aka, static arrays)
* Growable im/mutable lists, of im/mutable values (aka, dynamic arrays)
* Growable im/mutable maps, with hashed buckets, backed
     by red-black-trees (aka. associative arrays).

What about all the other types of containers?

* Sets/MutliSets/SortedSets (backed by hashtables or trees)
* SortedMaps/MultiMaps (backed by hashtables or trees)
* LinkedLists/SkipLists
* BinaryTrees/N-AryTrees/BTrees
* Heaps

Why the special syntax and compiler support for only a small portion of 
the container family? Really, shouldn't there also be a built in 'set' 
implementation as well?

And, while it's straightforward to develop multiple implementations of a 
standard container interface (like Map or List) with different data 
structures, it's impossible to replace the data structures backing an 
associative array or a dynamic array.

When an API developer writes a method expecting a map container (with 
keys and values), the developer is forced to choose between a 
polymorphic library implementation and a non-polymorphic associative 
array implementation):

   doSomething(Map!(K, V) map);
   doSomething(K[V] map);

The interface-based library implementation allows the function to accept 
multiple types of data structures, as long as they support the map 
interface. Users of the built-in assoc array function are stuck with the 
compiled-in implementation of the type.

And the built-in implementations don't play nicely with a full container 
library. Right now, the associative array type is defined as an 
*UNORDERED* collection, allowing no duplicate keys (but potential 
duplication of values). If you call its .keys property, you get back a 
dynamic array of its keys, but a dynamic array is an *ORDERED* 
collection that permits duplicates, so the returned collection distorts 
the contract of the collection that produced it.

A container library might implement a new Set interface, as an unordered 
collection of non-duplicate values. The consumers of the Map interface 
would probably like the Map.keys property to return a Set, since it 
paints a clearer picture of the Map contract.

But users of associative arrays won't be able to do the same. They'll be 
stuck with the built-in behavior.

Anyhow, those are just a few thoughts.

The built-in collection of types should include types with only one 
sensible implementation. A fixed-size list has only one sensible 
implementation: an array. So it makes sense for it to built in.

That's why I think the other types would be more at home in a library.

--benji