[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