https://d.puremagic.com/issues/show_bug.cgi?id=7597
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] 2014-04-08 08:19:34 PDT --- (In reply to comment #0) > Timon Gehr shows a case where defining a struct "init" method is useful, this > code compiles unless you de-comment the struct init. But maybe this is just a > bug in the implementation of @disable: > > > struct Foo { > @disable this(); > // @disable enum init = 0; > } > void main() { > Foo f = Foo.init; > } Arguably, the "Foo f = Foo.init;" *should* be guaranteed to *always* work. Finding a way to break it would be *catastrophic* for generic phobos code. The formulation is meant as a verbose way of saying - YES! I know that Foo is const/hasDisableThis, and I know I should be initializing it to an explicit value. But for gods sake, this is generic code and I need an instance regardless! Just use "T.init". I'll assume the consequences. More often than not, it is need for traits, where "f" would never be used anyways. It is also safer alternative to void initialization (that don't work with const anyways): should a throwing function be located between the declaration, and the subsequent emplace construction, at least, the destructor will be called on non-garbage, and the specs *do* say that T.init should always be destroyable. See also: https://d.puremagic.com/issues/show_bug.cgi?id=8752 Where Kenji suggests that some uses of "Foo f = Foo.init;" be made unsafe under certain situations. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
