On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:
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
It depends on what do you mean by type safety. If commonly
accepted definition is chosen (for example, what type safety
article means), than there is no type safety problem here.
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.
Yes, this is known. But note, that it is user, not the language,
who
circumvents initialization. By the way, what many people expect
from the feature - to have reference which points to
preallocated, valid object is hardly achievable in system level
language where due to free access to memory and memory bugs
reference may hold any value. For example, class object may turn
into integer with value 12345.
class A {}
int I = 12345;
A a = cast(A) I;
With the same reasoning I can say that language is faulting here
because it allowed for me to circumvent my own wishful(!)
assumption that references should always be allocated and point
to valid memory.
The fact that pointer or reference can be null, is a tiny, tiny
problem. You can test for null, but you cannot check whether
pointer contains valid address. For example, try to figure out
whether it is safe to write to address 0xFEFFABCD in some
particular context.
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.
As far as I remember the ability to define init property was
since 2.058. The semantic would that if you access init
explicitly, you would get overridden property, but in other cases
(for example allocation) the semantic is of language init.
Probably it was filed as a bug, I don't remember.
