Purity, @safety, etc., in generic code

[Timon Gehr]

On 02/25/2013 05:45 PM, deadalnix wrote:
> On Monday, 25 February 2013 at 16:35:52 UTC, Timon Gehr wrote:
>> The inout resolution of opSlice takes care of that.
>
> You got to be more precise about what you have in mind as I see plenty
> of way to make it fail (with static if for instance).  I see also how it
> can work in trivials cases, but we need more than that.

There is no question if it works, other languages have done a lot more 
than this. It is universal quantification. (using ad-hoc syntax 
elements. This is by no means how it should actually end up looking, in 
the unlikely case it is actually implemented.)

It can replace inout as follows:

int foo(inout int[] x) inout;

<=>

int foo[@type_constructor cons](cons int[] x) cons;

The benefit is that it allows multiple distinct type constructor 
variables, and that it works on aggregate declarations as well:

void foo[@type_constructor cons1, @type_constructor cons2](cons1 int[] 
x1, out cons1 int[] y1, cons2 int[] x2, cons2 int[] y2);

struct S[@type_constructor cons]{
     cons(int)[] x;
}

I do not see a less powerful mechanism that addresses the problems that 
Steven wants to address.