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.
