Bug 21277 – TypeInfo.initializer() is the wrong abstraction, should be TypeInfo.initialize(void*)

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2020-09-25T15:17:13Z
Last change time
2024-12-13T19:11:46Z
Assigned to
No Owner
Creator
Andrei Alexandrescu
Moved to GitHub: dmd#17989 →

Comments

Comment #0 by andrei — 2020-09-25T15:17:13Z
Currently: https://dlang.org/library/object/type_info.initializer.html This assumes every object is initialized by memcpying an array onto it. This makes it impossible to optimize initialization of objects with "= void" fields. The right abstraction is a method: void initialize(void* address); which creates a properly initialized object at address. That allows optimal initialization of objects with = void fields and may also save memory for all those static initializer arrays.
Comment #1 by moonlightsentinel — 2020-09-25T15:20:33Z
Shouldn't initialize rather accept a void[] instead of void* to detect errors, e.g. invalid size?
Comment #2 by andrei — 2020-09-25T15:28:33Z
(In reply to moonlightsentinel from comment #1) > Shouldn't initialize rather accept a void[] instead of void* to detect > errors, e.g. invalid size? Even better. Sadly (a) all other primitives use void*; (b) only size mismatches would be detected, not plenty of other errors, so the yield is low.
Comment #3 by kinke — 2020-09-26T12:32:39Z
IMO, a general problem of this method is the ambiguity for class types - initializer for a class *ref* or a class *instance*? [It's the latter.] There's also a tight interconnection with the core.lifetime.emplace() template, which uses it for classes and non-zero-init structs. emplace() takes a pointer to a class ref to initialize the ref with null, and a void[] to emplace a class instance.
Comment #4 by andrei — 2020-09-26T12:52:19Z
(In reply to kinke from comment #3) > IMO, a general problem of this method is the ambiguity for class types - > initializer for a class *ref* or a class *instance*? [It's the latter.] > > There's also a tight interconnection with the core.lifetime.emplace() > template, which uses it for classes and non-zero-init structs. emplace() > takes a pointer to a class ref to initialize the ref with null, and a void[] > to emplace a class instance. Good point. This is a low-level primitive not to be used naively, and emplace would use it. User-level code would use emplace. Point is, we don't have information about void fields. The proposed signature of initialize() would at least acknowledge their existence.
Comment #5 by kinke — 2020-09-26T13:04:44Z
(In reply to Andrei Alexandrescu from comment #4) > This is a low-level primitive not to be used naively, and > emplace would use it. User-level code would use emplace. In order to use emplace(), the user needs the type (not its TypeInfo). If all user code knew it, we wouldn't need this thing in TypeInfo at all, and could move all related logic to emplace().
Comment #6 by robert.schadek — 2024-12-13T19:11:46Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17989 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB