On 8/22/2015 5:47 AM, Iain Buclaw via Digitalmars-d wrote:
> But it should be put in COMDAT

And it is.

On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
>> 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.

I have always been in support of actually enforcing export on Linux (== making all non-export symbols hidden). It is a key for heavy cross-module optimization.

On Friday, 21 August 2015 at 21:50:21 UTC, Walter Bright wrote:
> As with everything, it's cost/benefit. Changing isnan to isNaN is an example of all cost and no benefit.
>
> I've explained the benefits of changing factory() a couple times in this thread. I believe the benefits are significant, including the benefit of making D viable for use in embedded systems.

This is fundamentally flawed way of thinking which only confirms my feeling that my last DConf talk was a complete waste. You completely ignore what those changes mean to your users by making such statements.

Changing isnan to isNaN is a small benefit (better internal structure and consistency is important) but it also comes at tiny, almost insignificant costs. It doesn't cause any immediate breakage and can be adjusted to at any moment with 1 simple search/replace. It is a best kind of change you can have, tier 1 ("good") in my classification.

Proposed change in Object.factory, on the other hand, is the worst possible kind of breaking changes you can ever make (tier 3, "ugly") - it changes program semantics silently at runtime with no errors and can't be adjusted to in automated manner, requiring full reimplementation of some designs. Cost of this change is huge, it will take no less than several full working days to fix everything.

Benefits are also not small - Mike use case is very important. Yet in current proposed form ration of cost/benefit is much much worse than one of isnan/isNaN - simply because how big costs are.

To make the change more acceptable you can take one of two possible paths:

1) make more benefits, for example by improving `export` definition and unifying its semantics between platforms (see also attribute inference / WPO proposals by Martin)
2) reduce costs by providing compiler diagnostics for transition and enabling similar designs at CT (see the issue I have linked earlier)

Doing both is perfection, of course.

On 8/23/2015 2:27 AM, Dicebot wrote:
> Changing isnan to isNaN is a small benefit (better internal structure and
> consistency is important) but it also comes at tiny, almost insignificant costs.
> It doesn't cause any immediate breakage and can be adjusted to at any moment
> with 1 simple search/replace. It is a best kind of change you can have, tier 1
> ("good") in my classification.

I agree the cost is small, but the benefit is zero. Yes, I understand you (and others) don't agree with my estimation of the benefit. I don't see much point in debating that one further, it's a done deal.


> Proposed change in Object.factory, on the other hand, is the worst possible kind
> of breaking changes you can ever make (tier 3, "ugly") - it changes program
> semantics silently at runtime with no errors and can't be adjusted to in
> automated manner, requiring full reimplementation of some designs. Cost of this
> change is huge, it will take no less than several full working days to fix
> everything.
>
> Benefits are also not small - Mike use case is very important. Yet in current
> proposed form ration of cost/benefit is much much worse than one of isnan/isNaN
> - simply because how big costs are.
>
> To make the change more acceptable you can take one of two possible paths:
>
> 1) make more benefits, for example by improving `export` definition and unifying
> its semantics between platforms (see also attribute inference / WPO proposals by
> Martin)
> 2) reduce costs by providing compiler diagnostics for transition and enabling
> similar designs at CT (see the issue I have linked earlier)
>
> Doing both is perfection, of course.

The point of this thread is to investigate the various ways of mitigating the costs and figure out the best way forward.

On Friday, 21 August 2015 at 06:24:34 UTC, Rikki Cattermole wrote:
> On 8/21/2015 5:06 PM, 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?
>
> I need to look over my code that I've written for my to be web application server.
> But: I'm a little concerned that if there is no alternative we won't be able to seriously be able to have a web application server ala JSP servlet style.
>
> So while export may work, perhaps a slightly different approach. If an interface/class is marked as export, it gets inherited. So an child class/implementation would also be export because a super interface/class was export.
> This would make me a lot happier.

I've had a look at it finally. This would definitely effect me.
Since TypeInfo_Class would still need to exist to access .init.

Humpth yes, it would be definitely desirable for me as the framework author to say every class that inherits from this interface must be visible to me. If it is not it is useless.
Transients would be desired in this use case. That way the average developer wouldn't have to worry about this behaviour.

On Saturday, 22 August 2015 at 20:22:58 UTC, 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").
>
>  — David

The good news is, once I'm done with my windows DLL work the code can be trivialy reused to make export control the visibility of symbols on linux as well.

Kind Regards
Benjamin Thaut

On 8/24/2015 1:09 AM, Benjamin Thaut wrote:
> The good news is, once I'm done with my windows DLL work the code can be
> trivialy reused to make export control the visibility of symbols on
> linux as well.
>
> Kind Regards
> Benjamin Thaut

Wait we are getting almost full blown DLL support on Windows?
Yuppie!

On Sunday, 23 August 2015 at 13:09:46 UTC, Benjamin Thaut wrote:
>
> The good news is, once I'm done with my windows DLL work the code can be trivialy reused to make export control the visibility of symbols on linux as well.
>
> Kind Regards
> Benjamin Thaut

But then you have the same problem on linux as on windows. "Export" controls not only the symbol visibility across shared library boundaries but also the module level visibility. E.g. this is a problem


private void SomeImplementationDetail() { ... }

void SomeTemplateFunc(T)()
{
  SomeImplementationDetail();
}


If you compile this into a shared library and all symbols are hidden by default unless marked with export it will fail to compile if someone tries to use it. Because the instanciated template SomeTemplateFunc will call the SomeImplementationDetail function which is not visible across the shared library boundary.

To fix this you would have to do:

export void SomeImplementationDetail() { ... }

void SomeTemplateFunc(T)()
{
  SomeImplementationDetail();
}

But this means that users of the shared library would suddenly be allowed to call SomeImplementationDetail.

The fix would be to make export an attribute instead of an protection level resulting in:

private export void SomeImplementationDetail() { ... }

void SomeTemplateFunc(T)()
{
  SomeImplementationDetail();
}

On Saturday, 22 August 2015 at 09:44:48 UTC, Martin Nowak wrote:
>
> The export seems to be an arbitrary rule (and export is really broken currently).
> Let's just use every class that is linked into the binary (e.g. weakly referencing them), then it'll naturally work with all linker functionalities.
>
> This doesn't only affect Object.factory but also ModuleInfo.localClasses.
> I'd suggest we first add a new internal array of weakly linked classes, turn localClasses into an opApply function or range so it automatically skips null classes (weakly undefined), then change Object.factory to only load weakly linked classes.
>
> For an intermediate time we can keep the old array and print a deprecation warning in Object.factory when a class would no longer be available.
> https://github.com/D-Programming-Language/dmd/pull/4638

How do you implement weak linking? It would be really usefull for my DLL work as well, but I couldn't find any way to make it work with the microsoft linker.

On 8/23/2015 6:17 AM, Benjamin Thaut wrote:
> How do you implement weak linking? It would be really usefull for my DLL work as
> well, but I couldn't find any way to make it work with the microsoft linker.

I've always had trouble with linker bugs when using weak linking, to the point where I simply gave up on using it.