On Saturday, 14 June 2014 at 15:22:07 UTC, Andrei Alexandrescu
wrote:
On 6/14/14, 5:33 AM, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it
does is disallow instantiating the type without specifying an
initializer (e.g. a struct literal, a value returned from a
factory
function, or `static opCall()`).
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
I disagree it's a loophole. A.init is a preexisting object.
That said, I do understand that sometimes one wants to inhibit
A.init, which can be achieved by e.g. making it a private
member. -- Andrei
By that rational, so is "void". If you want default initial
state, you just use "A()".
Using "A.init" is just the same as using "void": It's "fuck you
compiler I'm know what I'm doing."
I strongly oppose any notion of being able to customize ".init"
value or access: It should be a built in and well defined
concept. If we do allow things like that, than *any* low level
function, such as emplace, move, swap, destroy or even __ctor
will exibit unspecified behavior.
".init" should simply mean "the default bit state of the object".
Let's not make it into anything more complicated than that.
