inout and function/delegate parameters

[Timon Gehr]

On 02/19/2012 06:09 PM, Stewart Gordon wrote:
> On 19/02/2012 15:31, Timon Gehr wrote:
> <snip excessive quote>
> <snip>
>> a) int opApply(inout int delegate(ref inout(T)) dg) inout;
>> b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;
>
> ???

oops...

a) int opApply(inout int delegate(ref inout(T)) dg) inout;
b) int opApply(int delegate(ref inout(T)) dg) inout;

>
>> Actually affecting the constancy of the delegate itself is not an
>> useful operation anyway,
>> but it could still be achieved:
>>
>> a) int opApply(inout inout(int delegate(ref inout(T)))) dg) inout; //
>> every inout means
>> the same thing
>
> So "inout inout" would be a special token sequence to link the outer and
> inner inouts together.

No, but probably it is more clear with the fixed b) case above. The 
inout parameter storage class would be used for linking.

>
>> b) int opApply(inout(int delegate(ref inout(T)))) dg) inout; // the
>> inout on the delegate
>> parameter is distinct from the other two
>
> I don't see what the inout applied to the type of dg is actually doing
> here....
>
>> 2.
>>
>> We introduce an infinite number of wildcard storage classes:
>> inout, inout', inout'', inout''', inout'''', ...
> <snip>
>> [1] furthermore, we'd finally get identifier' identifiers ;)
>
> The lexer would need to be tweaked to support these. And it might get
> confusing to overload ' like this, given that some other keywords can be
> immediately followed by a character literal.

I am not aware of any except 'case'. But you are right. It would 
certainly confuse most existing D editors.

>
> Maybe inout$ with some kind of identifying token....
>
> (a) int opApply(int delegate(ref inout$0(T)) dg) inout$0;
> (b) int opApply(int delegate(ref inout$1(T)) dg) inout$0;
>
> Hmm....
>
> Stewart.

That would be a possibility.