Purity, @safety, etc., in generic code

[Steven Schveighoffer]

On Mon, 25 Feb 2013 13:36:18 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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.

I actually proposed this to Walter a few years ago (same concept,  
different syntax).  He said it was a solid proposal, and added too much  
complexity for the value.

What I am trying to come up with is a simplification.  I will post  
sometime soon what I think will work.  We definitely need something.

-Steve