Go and generic programming on reddit, also touches on D

[Timon Gehr]

On 09/19/2011 01:25 PM, Steven Schveighoffer wrote:
> On Sun, 18 Sep 2011 15:34:16 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 09/18/2011 08:28 PM, Andrei Alexandrescu wrote:
>>> That would allow us to e.g. switch from the
>>> pointer+length representation to the arguably better pointer+pointer
>>> representation with ease.
>>
>> In what way is that representation better?
>
> I agree, I don't see why the representation is inherently better. Some
> operations become higher performance (i.e. popFront), and some become
> worse (i.e. length). Most of the others are a wash.
>
> FWIW, you can avoid bloat by converting to runtime calls when templating
> is not necessary. For example, append could just be a template shell:
>
> opBinary(string op : "~=")(T other)
> {
> return _d_appendTi(...) // don't remember the parameter types/order
> }
>

Ok, but I'd like the opBinary to not even be put into the object file. I 
believe an @inline annotation that guarantees inlining or compilation 
failure if it is impossible would be of great use for this and other 
applications.

> In any case, before this could happen, we'd need to implement UFCS for
> custom types,

First of all, the design of UFCS for custom types has to be settled on. 
Should it be implicit like the current ad-hoc way for arrays or explicit 
(eg per a 'this' storage class) ? I would be in favor of an explicit 
solution.

> and we'd need a solution on how to specify const(T)[]
> using a template (that implicitly casts from T[]).
>

Even more than that, templates would need to be able to specify stuff like

// the fact that this currently compiles is a quite severe bug that 
compromises type/memory safety, it would have to be disallowed without 
an explicit cast:

class C{}
class D: C{}
class E: C{}

void main(){
     D[] d = [new D];
     C[] c = d;
     c[0] = new E;
     assert(typeid(d[0]) == typeid(E)); // a stray E in a D[]!
}

// this on the other hand is perfectly fine:
void main(){
     D[] d = [new D];
     const(C)[] c = d;
     // no possibility to screw up d. (no possibility to change the 
individual elements per method calls either)
}

As I pointed out in my initial post, I think the language changes to 
make something that works like a dynamic array implementable in a 
library would be quite involved, because there _is_ some nontrivial 
magic going on for them. Similar claims hold for pointers.

Probably having something ad-hoc, like an opImplicitCast, would work 
out, but it would share some functionality with alias this...

Still, imho the best solution is to keep dynamic arrays built in, 
whether or not their special features are made available to the programmer.