[Issue 7597] Statically disallow a init() method in structs

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=7597


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #1 from monarchdodra at gmail.com 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: -------