On Tuesday, 6 August 2013 at 02:11:54 UTC, Timon Gehr wrote:
I thought I had demonstrated that it buys you more. It resolves
the problem that scoping is ambiguous and that there can be
only one 'inout' substitution per function application.
It may look ambiguous to someone who doesn't know, how the
feature works, because it's implicit, which, again, is a
tradeoff. Subjective ambiguity should be solvable with better
docs, learning resources and tutorials.
Why? It is the same kind of problem.
They differ in scale. Const overloads are an overwhelming problem
in OO design, which is vaguely demonstrated in DIP2.
Of course. Just push the parameter to the instantiated struct
type.
i.e.
struct S(T){
T field;
}
S!(C(int)*) foo[TC C](C(int)* p){ return typeof(return)(p); }
Would behave like:
struct S[TC C]{ // (template instance)
C(int)* field;
}
S![C] foo[TC C](C(int)* p){ return typeof(return)(p); }
Ah, an opaque template parameter? It may have value in itself and
not require a new syntax or restricted to type qualifiers.
The fix is to introduce proper scoping, but then it does not
seem sensible to only allow one name for the type constructor
parameter.
inout already has proper scoping: data external to the function
shouldn't be qualified as inout, it just should be checked.
