Ironclad C++

[Kagamin]

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 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.
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. Const system doesn't interoperate with templates 
well. You don't have a solution either, 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.

I was thinking to call for lore about issues with inout and solve 
them, also for other people, who want to work on the type system 
to have an estimate of the problem's scale. Am I late?