On 09/19/2011 01:25 PM, Steven Schveighoffer wrote:
On Sun, 18 Sep 2011 15:34:16 -0400, Timon Gehr <timon.g...@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.
