On 2015-08-21 22:26, Walter Bright wrote:

> The principle often used by languages (C, C++, Rust) is you only pay for
> what you use. With Object.factory, every program pays for it with every
> class, despite very few actual uses of it.

A always thought of D as a bit more convenient language. Variables are automatically initialized, virtual by default, minimal reflation functionality, i.e. Object.factory.

Although, all of these can be avoided except for Object.factory.

-- 
/Jacob Carlborg

On 2015-08-21 07:06, 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.

If we're actually going to talk about solution then it seems better to have a flag that disables Object.factory. It won't break any code and everyone that doesn't like can disable it. Everybody wins.

-- 
/Jacob Carlborg

I think this is another case where Walter has got it right, by and large. I think we should try and use 'export' to cut down on binary bloat, and it looks like an acceptable solution.

I have said many times, lock your versions down, and don't update your D compiler until you're ready to pay the cost of updating. There is always a cost involved, small or great.

On 2015-08-25 10:18, w0rp wrote:
> I think this is another case where Walter has got it right, by and
> large. I think we should try and use 'export' to cut down on binary
> bloat, and it looks like an acceptable solution.
>
> I have said many times, lock your versions down, and don't update your D
> compiler until you're ready to pay the cost of updating. There is always
> a cost involved, small or great.

I'm been doing that and I get a lot of complains from developers how want to use my libraries with later versions of the compiler.

-- 
/Jacob Carlborg

V Tue, 25 Aug 2015 10:34:57 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On 2015-08-25 10:18, w0rp wrote:
> > I think this is another case where Walter has got it right, by and large. I think we should try and use 'export' to cut down on binary bloat, and it looks like an acceptable solution.
> >
> > I have said many times, lock your versions down, and don't update your D compiler until you're ready to pay the cost of updating. There is always a cost involved, small or great.
> 
> I'm been doing that and I get a lot of complains from developers how want to use my libraries with later versions of the compiler.
> 

As a library author (ideal case) you need to support both, some stable
branch and some development branch ;-).

On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:

>> A MUCH better solution:
>>
>> T[] _d_arrayliteral(T)(size_t length)
>>
>> Also, isn't the typeinfo now stored by the GC so it can call the dtor? Perhaps that is done in the filling of the array literal, but I would be surprised as this is a GC feature.
>>
>>
> I only looked at 2.066.1, the runtime implementation did not pass the typeinfo to the GC.

_d_arrayliteralTX eventually calls structTypeInfoSize() which, according to https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214, is used to determine the size of TypeInfo so it can be stored by the GC, as Steven said.

Mike

On 26 August 2015 at 15:14, Mike via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:
>
> A MUCH better solution:
>>>
>>> T[] _d_arrayliteral(T)(size_t length)
>>>
>>> Also, isn't the typeinfo now stored by the GC so it can call the dtor? Perhaps that is done in the filling of the array literal, but I would be surprised as this is a GC feature.
>>>
>>>
>>> I only looked at 2.066.1, the runtime implementation did not pass the
>> typeinfo to the GC.
>>
>
> _d_arrayliteralTX eventually calls structTypeInfoSize() which, according
> to
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214,
> is used to determine the size of TypeInfo so it can be stored by the GC, as
> Steven said.
>
> Mike
>
>
Well, I have no control over what the library maintainers in DMD want to do in their runtime, but all is working fine without doing that in my camp.

On 8/26/15 10:50 AM, Iain Buclaw via Digitalmars-d wrote:
> On 26 August 2015 at 15:14, Mike via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:
>
>             A MUCH better solution:
>
>             T[] _d_arrayliteral(T)(size_t length)
>
>             Also, isn't the typeinfo now stored by the GC so it can call
>             the dtor? Perhaps that is done in the filling of the array
>             literal, but I would be surprised as this is a GC feature.
>
>
>         I only looked at 2.066.1, the runtime implementation did not
>         pass the typeinfo to the GC.
>
>
>     _d_arrayliteralTX eventually calls structTypeInfoSize() which,
>     according to
>     https://github..com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214
>     <https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L214>,
>     is used to determine the size of TypeInfo so it can be stored by the
>     GC, as Steven said.
>
>     Mike
>
>
> Well, I have no control over what the library maintainers in DMD want to
> do in their runtime, but all is working fine without doing that in my camp.
>

The change was to make it so struct dtors are called by the GC.

-Steve