[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