[Issue 13678] TypeInfo.initializer is inconsistent

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sun Jan 17 20:24:04 PST 2016


https://issues.dlang.org/show_bug.cgi?id=13678

Marco Leise <Marco.Leise at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|TypeInfo.init is            |TypeInfo.initializer is
                   |inconsistent                |inconsistent

--- Comment #3 from Marco Leise <Marco.Leise at gmx.de> ---
(In reply to Steven Schveighoffer from comment #2)
> As far as I know, there is no mechanism to say you shouldn't initialize the
> data.

That is correct and my thinking is that this was due to the .init/.initializer
property being underspecified, since we do have it in the language:

  struct Output
  {
      double[1024] data = void;
  }

Instead of:

null => initializer is all zeroes
array of correct length => initializer contains non-zero bytes

we could also define three states:

ptr is null, length is correct => initializer is all zeroes
ptr is null, length == 0 => initializer is void
else => initializer contains non-zero bytes

This would allow us to avoid a memset where the data structure is explicitly
declared with all void initializers.

Where the type is statically known, 'x = T.init' can still be more effective,
because the compiler can freely chose how to initialize a data structure, based
on whether x is already initialized or not, T.init contains a mix of void and
non-void fields or if one or more of the fields are overwritten shortly after.
typeid(T).initializer is the more blunt tool. T.init is a compiler intrinsic,
typeid(T).initializer is data.

--


More information about the Digitalmars-d-bugs mailing list