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
