On Saturday, 19 October 2013 at 09:26:53 UTC, Max Samukha wrote:
On Saturday, 19 October 2013 at 08:45:05 UTC, Maxim Fomin wrote:
Actually aggregate name of collection was "(collection of
memory
errors, type system breakages and other cases to shoot your
foot
provided by bugzilla issues, me and other people)".
And we are back to square one - misusing extern(C) and
reflection to call the constructor as you showed in #13 does
not belong in that collection.
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?
