Ironclad C++

[Kagamin]

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.