http://d.puremagic.com/issues/show_bug.cgi?id=8752

           Summary: Unsafe use of T.init should be allowed in @system
                    function
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k.hara.pg@gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg@gmail.com> 2012-10-04 05:03:01 PDT ---
I think that T.init should be always legal expression for any T. But, I also agree that T.init _sometimes_ *unsafe*.

1) If T has @disable this(), T.init will returns an object which just
initialized (== the value itself is never undefined), but not
constructed (might be logically invalid object).
2) If T is nested struct, it's frame pointer is always null. It might
cause access violation by its member function call.

To relax the dilemma, I'd like to propose following restriction which enforced by the compiler.

If T.init is unsafe (T is nested struct, or has @disable this();) , it will be
annotated with @system, then could use it only inside @system and @trusted
functions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8752


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-12-16 17:35:37 PST ---
Given that using init is _almost_ always safe and that functions are @system by default, I don't know how good an idea this is. It will be _really_ easy for someone to use T.init with @disable, not realizing what they're doing. If @safe were the default, then maybe, but this just seems too dangerous to me. I could see an argument for always being able to use T.init in template constraints and the like, but it seems to me like it's going too far to allow @disabled init's to work in @system code. And depending, allowing T.init in template constraints and other metaprogramming poses its own risk, because while T.init often used to determine stuff about a type without actually using T.init in the code, there's no way to know whether the purpose of the test is to test something about T by using T.init or if the purpose is to test whether T.init itself actually works in they way that the constraint is testing for. So, I'm inclined to think that we need another solution for this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------