On 08/05/2013 10:44 PM, Kagamin wrote:
On Sunday, 4 August 2013 at 15:04:48 UTC, Timon Gehr wrote:
- No naming or scoping:
OK, but I'm not sure naming and scoping buys you anything except for
being more explicit, but explicity vs implicity is a tradeoff.
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.
I kinda understand the argument about dependent purity, but the problem
with purity arises mostly in generic code consuming arbitrary ranges,
the problem with delegate purity looks minor.
Why? It is the same kind of problem.
As to the crash, it looks like it tries to mess with the delegate's
signature, which it souldn't do: delegate's signature doesn't
participate in const transitivity rules. The cost is probably one if at
the right place.
- Only works for parameters or stack based variables:
Not a failure to not do what is not proved to be possible and
acceptable.
Those ideas are more than 40 years old and this is a minor adaptation.
Const system doesn't interoperate with templates well.
You don't have a solution either,
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); }
even with your universal notation, right?
- Plain unsoundness of current type checking approach:
Closures were not covered in DIP2 (I agree, that was a major overlook).
Closured variables should be treated as external to the closure and
either be seen as const or require cast to const. Fix may be
non-trivial, but possible.
...
The fix is to introduce proper scoping, but then it does not seem
sensible to only allow one name for the type constructor parameter.
