Ironclad C++

[Timon Gehr]

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.