Go and generic programming on reddit, also touches on D

[Andrei Alexandrescu]

On 9/18/11 11:08 AM, Timon Gehr wrote:
> On 09/18/2011 03:48 AM, Andrei Alexandrescu wrote:
>> Quite interesting.
>>
>> http://www.reddit.com/r/programming/comments/kikut/think_in_go_gos_alternative_to_the/
>>
>>
>>
>
> 2 hours ago, Andrei Alexandrescu wrote:
>  > The problem is, Vector was just an example of a multitude of
> containers. The huge problem with slices is dogfood-related - they are >
> "magic" because the language features proposed to programmers were not
> enough for expressing a simple abstraction. Reserving "special" features
> for the language is a terrible way to go about programming language design.
>
> Don't D arrays do a similar thing? They are not templates, yet work with
> generic element types.
>
> Afaics, improving the language to the point were dynamic array-like
> structures could be implemented in the library without resulting in a
> bloated executable would be quite involved.

That's an incorrect view of my statement. Yes, D's slices are built-in 
but the language offers facilities for defining any other parameterized 
types that are just as powerful. The only advantages slices have left 
are (a) type syntax, i.e. T[] instead of Slice!T, (b) literal syntax, 
i.e. [ 1, 2, 3 ] instead of slice(1, 2, 3), and (c) a couple of stray 
language bugs such as '$'.

Walter and I have long discussed that T[] should use an actual type 
object.Slice!T as back-end. That would allow us to e.g. switch from the 
pointer+length representation to the arguably better pointer+pointer 
representation with ease. The main difficulty with object.Slice is CTFE 
- the compiler can manipulate a T[] during compilation because it 
understands its invariant. The same invariant would be difficult to 
infer from a user defined type.


Andrei