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.
Hole in the type system: yes
Necessarily a bad thing: no
Some data-types require runtime initialisation to be valid. By
using .init you are explicitly circumventing any runtime
initialisation. It's an explicit hole, just like cast.
It appears that it possible (in 2.065 at least) for a struct to
provide it's own init, which can of course be
template init() { static assert(false); }
Is the ability to manually specify .init a bug or a feature? I
feel like it's a bug.
I would like to see a logicalInit added to druntime/phobos and
adopted where appropriate instead of .init
auto logicalInit(T)()
{
static if(hasMember!(T, "logicalInit"))
{
return T.logicalInit;
}
else
{
return T.init;
}
}
and then types can define their own logicalInit, whether it's
just a static assert or something else. Perhaps it should be
limited to compile-time values only to avoid it being a default
constructor workaround.
