On 22 August 2015 at 11:33, Johannes Pfau via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Am Fri, 21 Aug 2015 15:16:01 +0200
> schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:
>
> >
> > Other than that, the semantics of pragma(inline, true) should guarantee that the function is never *written* to object file.
> >
>
> This really should be documented then. If we build a shared library with pragma(inline) functions not emitting the function prevents taking the address of that function in all client code. As this is a breaking change to 'normal' inline semantics it needs to be documented.
>
> https://github.com/D-Programming-Language/dlang.org/pull/1073
>

I wouldn't go as far as preventing these functions from having their address taken.  In that instance, of *course* it needs to be written to object file.  But it should be put in COMDAT as each external module that takes its address will have a copy of it.

Regards
Iain.

Am Sat, 22 Aug 2015 14:47:34 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 22 August 2015 at 11:33, Johannes Pfau via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> 
> > Am Fri, 21 Aug 2015 15:16:01 +0200
> > schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:
> >
> > >
> > > Other than that, the semantics of pragma(inline, true) should guarantee that the function is never *written* to object file.
> > >
> >
> > This really should be documented then. If we build a shared library with pragma(inline) functions not emitting the function prevents taking the address of that function in all client code. As this is a breaking change to 'normal' inline semantics it needs to be documented.
> >
> > https://github.com/D-Programming-Language/dlang.org/pull/1073
> >
> 
> I wouldn't go as far as preventing these functions from having their address taken.  In that instance, of *course* it needs to be written to object file.  But it should be put in COMDAT as each external module that takes its address will have a copy of it.
> 
> Regards
> Iain.
> 

That's indeed a better solution.

On 8/22/2015 2:42 AM, Dicebot wrote:
> On Friday, 21 August 2015 at 20:28:47 UTC, Walter Bright wrote:
>>> Btw we use it for high-level testing framework - will be rather hard to move
>>> that to compile-time approach
>>
>> It's good to hear of use cases for Object.factory.
>
> If you want details it is special library for black box testing applications by
> spawning them as external processes and interacting with their shell/network
> API. To minimize boilerplate test scenarios are derived from special TestCase
> class and test runner finds all classes that derive from TestCase automatically.
>
> Marking them all as export will be inconvenient but is possible - but I'd like
> to get something useful in return, like well-defined and working export for
> example.

I'm not sure how export would help on Linux.


>> > until some reflection bugs gets fixed.
>>
>> Bugzilla issues? (You knew that was coming!)
>
> https://issues.dlang.org/show_bug.cgi?id=11595 is the main offender. Currently
> the task 'find all symbols with a given trait in the whole program' can't be
> implemented at CT.

Thanks!

On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
> I'm not sure how export would help on Linux.

One of the use cases for export on Linux would be to set the ELF visibility based on it. Emitting all the symbols with default visibility, like we currently do, leads to size and load time problems with large libraries. Big C++ projects are plagued regularly by this (cf. "-fvisibility=hidden").

 — David

On 8/22/2015 1:22 PM, David Nadlinger wrote:
> On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
>> I'm not sure how export would help on Linux.
>
> One of the use cases for export on Linux would be to set the ELF visibility
> based on it. Emitting all the symbols with default visibility, like we currently
> do, leads to size and load time problems with large libraries. Big C++ projects
> are plagued regularly by this (cf. "-fvisibility=hidden").

A bugzilla enhancement request for this would be nice.

On Saturday, 22 August 2015 at 21:56:25 UTC, Walter Bright wrote:
> On 8/22/2015 1:22 PM, David Nadlinger wrote:
>> One of the use cases for export on Linux would be to set the ELF visibility
>> based on it. Emitting all the symbols with default visibility, like we currently
>> do, leads to size and load time problems with large libraries. Big C++ projects
>> are plagued regularly by this (cf. "-fvisibility=hidden").
>
> A bugzilla enhancement request for this would be nice.

https://issues.dlang.org/show_bug.cgi?id=9893

 – David

On Saturday, 22 August 2015 at 22:08:50 UTC, David Nadlinger wrote:
>> A bugzilla enhancement request for this would be nice.
>
> https://issues.dlang.org/show_bug.cgi?id=9893


The common saying "if it isn't in bugzilla it is forgotten" seems quite silly when so much that IS in bugzilla is forgotten all the same.

On 8/22/2015 3:41 PM, Adam D. Ruppe wrote:
> The common saying "if it isn't in bugzilla it is forgotten" seems quite silly
> when so much that IS in bugzilla is forgotten all the same.

Lots of people, like Daniel and Kenji and Vladimir and Martin, etc., go through Bugzilla looking for things to fix.

I don't know anyone combing through the 300,000 messages in this n.g. looking for vaguely described complaints to fix.

Furthermore, the changelog for each release shows hundreds of bugzilla issues fixed, and 0 newsgroup complaints fixed.

On 21 August 2015 at 15:06, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> 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?

I don't follow the reasoning, but yes! Kill it with fire!
I'd rather see a compile option or something to disable it completely,
like how disabling RTTI is a common C++ option.

On Saturday, 22 August 2015 at 23:33:15 UTC, Manu wrote:
> On 21 August 2015 at 15:06, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> I don't follow the reasoning, but yes! Kill it with fire!
> I'd rather see a compile option or something to disable it completely,
> like how disabling RTTI is a common C++ option.

rtti is used heavily in the runtime hooks, this needs to be fixed first as far as I know.