Safe mode in D?

[Max Samukha]

On Saturday, 19 October 2013 at 10:50:42 UTC, Maxim Fomin wrote:

> OK, you can remove extern(c) trick (however, it is not clear, 
> why it shouldn't be counted as a type system hole) and you 
> still have "reflection hole".
>
> I came up with the code in response to Andrei who said that 
> constructor control flow is "primitive but quite adequate" and 
> which "is already implemented and works". What "primitive but 
> quite adequate" does mean is subjective, but it does not really 
> prevent from what it is suppose to prevent. Of course in this 
> case you do not corrupt memory or write to immutable (I am 
> telling this for the third time). The point was made why would 
> you have such constraint if it is easily avoidable? How much 
> sense is in the constraint which does not provide real value 
> (except probably as an exercise in implementing abstract 
> programming theories from academia) nor is properly reinforced?

The question is what it takes to close every possible hole. .NET 
designers apparently decided not to close the reflection hole 
because the cost (in various senses) would be too high.