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

           Summary: "= void" initialization should not be allowed in @safe
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: m.strashun@gmail.com


--- Comment #0 from Dicebot <m.strashun@gmail.com> 2013-05-29 08:23:23 PDT ---
Compiles in 2.063:

------------
@safe void foo()
{
   int x = void;
}
------------

Reporting because Andrei has clearly stated this is not intentional: http://forum.dlang.org/post/ko55pi$2upp$1@digitalmars.com

-- 
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=10201



--- Comment #1 from Dicebot <m.strashun@gmail.com> 2013-05-29 08:42:06 PDT ---
Additional explanation - it does report an error if initialized value is a pointer or contains a pointer. It does not report an error if value has disabled constructor though.

So it is not that dangerous in that sense, but can be used to workaround some guarantees provided by disabled constructor. Prohibiting all void initalizers in @safe may be both more simple and consistent.

-- 
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=10201


monarchdodra@gmail.com changed:

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


--- Comment #2 from monarchdodra@gmail.com 2013-07-26 13:05:21 PDT ---
(In reply to comment #1)
> So it is not that dangerous in that sense, but can be used to workaround some guarantees provided by disabled constructor. Prohibiting all void initalizers in @safe may be both more simple and consistent.

It is dangerous in the sense that for a struct that is not POD, you are violating its internal integrity, at which point, it has no way to guarantee the safety of its own internal operations.

I mentioned this in https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment-21644766 with the example:

//----
struct S
{
    private size_t index;
    private ubyte[1] arr;

    ref ubyte get() @trusted
    {
        return arr.ptr[index];
    }
}

void main() @safe
{
    S s = void;
    ubyte a = s.get();
}
//----

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