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.
