On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
> This function:
>
>   http://dlang.org/phobos/object.html#.Object.factory
>
> enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat:
>
>   https://issues.dlang.org/show_bug.cgi?id=14758
>
> and sometimes the bloat can be overwhelming.
>
> The solution seems straightforward - only have Object.factory be able to instantiate classes marked as 'export'. This only makes sense anyway.
>
> What do you think?

Just change Object.factory to require registration of the class. It isn't too much of an effort to designate the few classes where it's needed, really. It's even safer, because the class name could potentially come from user input, and needs to be sanitized anyway in this case.

On Friday, 21 August 2015 at 11:03:09 UTC, Mike wrote:
> * postblit - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918
> * destructor - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR1039

Looks like these are generated for fixed sized array of structs in a struct.

> * slicing - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R11857

Can't even understand, what is this. Array op? But array ops are handled just above.

On 8/21/15 7:39 AM, Dicebot wrote:
> On Friday, 21 August 2015 at 11:34:58 UTC, Steven Schveighoffer wrote:
>> A MUCH better solution:
>>
>> T[] _d_arrayliteral(T)(size_t length)
>
> It needs to be trivial wrapper which forwards to proposed
>
>> void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint flags, bool
>> isshared);
>
> Otherwise you get another binary bloat issue.

Sure:

pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)

-Steve

On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
> Sure:
>
> pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
>
> -Steve

Btw, are `pragma(inline, true)` function actually guaranteed to not have own code gen? :)

On 8/21/15 7:57 AM, Dicebot wrote:
> On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
>> Sure:
>>
>> pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
>>
>> -Steve
>
> Btw, are `pragma(inline, true)` function actually guaranteed to not have
> own code gen? :)

I have no idea. It probably should be guaranteed, because what is the point of having an "always inlined" function that generates it's own code?

But if you took the address of it, it would need the code to be generated. Not sure what happens there, probably should be an error.

-Steve

On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer wrote:
> I have no idea. It probably should be guaranteed, because what is the point of having an "always inlined" function that generates it's own code?

If it is guaranteed, almost makes me want to abuse it for this:

pragma(inline, true)
string foo()
{
    if (!__ctfe)
        assert(false);
    // ...
}

(for compilers other than LDC)

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
> This function:
>
>   http://dlang.org/phobos/object.html#.Object.factory
>
> enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat:
>
>   https://issues.dlang.org/show_bug.cgi?id=14758
>
> and sometimes the bloat can be overwhelming.
>
> The solution seems straightforward - only have Object.factory be able to instantiate classes marked as 'export'. This only makes sense anyway.
>
> What do you think?

An alternative which would be more work but wouldn't break code would be to put the "all the classes" structure in a separate section, which is only referenced by Object.factory. Thus, the structure will be GC-ed by the linker, unless Object.factory is actually used somewhere in the program.

Not sure how this would tie in with shared objects though. Maybe this needs to be combined with your "export" idea.

On 21 August 2015 at 14:43, Dicebot via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer wrote:
>
>> I have no idea. It probably should be guaranteed, because what is the point of having an "always inlined" function that generates it's own code?
>>
>
> If it is guaranteed, almost makes me want to abuse it for this:
>
> pragma(inline, true)
> string foo()
> {
>     if (!__ctfe)
>         assert(false);
>     // ...
> }
>
> (for compilers other than LDC)
>

That enforces that foo() is always folded at compile time, not always
inlined, no?

On 21 August 2015 at 13:57, Dicebot via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
>
>> Sure:
>>
>> pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
>>
>> -Steve
>>
>
> Btw, are `pragma(inline, true)` function actually guaranteed to not have
> own code gen? :)
>

For compilers other than DMD, their code needs to be generated to allow the backend to inline/optimize calls away - something that I'm pretty sure is not done when calling a pragma(inline, true) function that lives in another module.

Other than that, the semantics of pragma(inline, true) should guarantee that the function is never *written* to object file.

Regards
Iain

On 2015-08-21 10:52, Benjamin Thaut wrote:

> Yes, the usual problem was that it only works with default constructors.
> Also it doesn't work with nested classes e.g.
>
> class Outer
> {
>    class Inner
>    {
>    }
> }
>
> I don't know if that is fixed now.

It sounds like both of these could be fixed. BTW, in my serialization library I don't even call the constructor so I don't have that problem.

-- 
/Jacob Carlborg