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