Possible change to array runtime?
sclytrack
sclytrack at sexy.com
Thu Mar 13 15:21:55 PDT 2014
On Thursday, 13 March 2014 at 21:28:46 UTC, deadalnix wrote:
> If I may, and as author of dcollection, you'll certainly agree,
> I
> think the way forward is improving the language when it comes to
> collections.
>
> That way, any behavior can be provided as user type. Patching
> the
> language in such a way is simply moving the problem around.
>
> The #1 problem we have when it comes to collection is type
> qualifier for template type parameters. I consider this to be on
> of the top problems of D right now, if not the #1 problem.
>
> The problem is that T!ElementType is a ompletely different type
> than T!const(ElementType) . Because of this, if is almost
> impossible to provide anything that behave anything close to
> arrays. That is th reason why collection are so scarce in D,
> this
> is the reason why efforts to implement AA without the black
> magic
> involved right now are failing.
>
> This problem is a killer for the viability of D2 on the long
> run.
> I'm not saying that lightly.
Language changes? Like this?
-------------
Delayed D Language D Normal
immutable int * a; int * a;
immutable qual(int) * a; immutable(int) * a;
immutable int qual(*) a; immutable int * a;
-------------
struct A
{
int a;
qual(int) b;
}
A vari;
const A cvari;
vari.a = 1;
cvari = vari;
cvari.a = 2;
cvari.b = 3; //error
-------------
qual
class Test
{
}
Delayed D D struct language
immutable Test t; immutable(Test) * t;
immutable qual(Test) t; immutable Test * t;
-------------
struct Array(T)
{
qual(T) * data;
size_t length;
}
Array!(int) a;
const Array!(int) b;
void routine(const Array!(int) b)
{
}
b = a;
routine(a);
More information about the Digitalmars-d
mailing list