www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8752] New: Unsafe use of T.init should be allowed in system function

reply d-bugmail puremagic.com writes:
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: -------
Oct 04 2012
parent d-bugmail puremagic.com writes:
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: -------
Dec 16 2012