Am Thu, 17 Jul 2014 08:05:33 +0100 schrieb Iain Buclaw via Digitalmars-d <[email protected]>:
> On 17 July 2014 07:09, Walter Bright via Digitalmars-d > <[email protected]> wrote: > > On 7/16/2014 1:12 PM, Johannes Pfau wrote: > >> > >> I'll take this as you pre-approve all the mentioned extensions? > >> > >> * way to disable typeinfo for struct > > > > > > Worth investigating. It'd probably be much more effective to work > > the linker angle of removing items for which no references exist. > > Martin was working on that, but his latest attempt had to be > > reverted, as it needed a new approach. > > > > > > > >> * way to disable initializer > > > > > > T t = void; // no initialization I'm referring to the __initZ symbol/data, it gets emitted even if all fields of a struct are =void initialized. > > > > > >> * force inlining > > > > > > http://wiki.dlang.org/DIP56 (Note the author!) > > > > For the time being, GDC has @attribute("forceinline") > > https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/attribute.d > Yes. We'll have to take a look if we can prevent the function from appearing in the object file (with force inline, there's no need to keep the function, it must always be inlined anyway) > > >> * (way to omit copy constructor function / force inline) > > > > > > I don't know what that means > > @disable this(this); ? > > I'll let Johannes clarify. > I was referring to the implicitly generated __cpctor not the postblit. As it's implicitly generated you can't put @force-inline on it. This applies to all compiler generated functions though, __fieldPostBlit, __fieldDtor autogenerated opAssign and probably some more. However, simple (POD?) types are probably not affected as those don't get a __cpctor IIRC?
