On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default
initialization,
not to reject potentially buggy one.
Well consider imaginary NotNullable struct that uses "@disable
this()" to guarantee that instance of that struct always has
meaningful state. By using (NotNullable!T).init you can get
value of that type which is in fact null and pass it as an
argument to function that expects NotNullable to always be non
null. With no casts involved you have just circumvented
guarantees static type system was suppose to give.
You can complain if language itself produces code which accesses
init property. This would be violation of disable premise.
However, it is clearly you who intentionally asked init property,
so there is no language fault here.
For example, some time ago implicit disable struct creation
issues (in context of array copy, out parameter, etc. ) were
filed and fixed. If you face situation when compiler generates
default disabled struct without user permission, this would be a
bug.
The case which you described is a not a type safety problem.
There is no reinterpretation of object of one type as another
type (or reading/writing memory which should not have been
read/written). It is perfectly safe to assign object of type A to
the same type. What is presented is some sort of design pattern
violated by the user, not the language (and the goal of the
pattern cannot be fully achieved in D language).
