Updated DIP22 - Private symbol visibility

Timon Gehr timon.gehr at gmx.ch
Sat Dec 21 12:18:50 PST 2013


On 12/21/2013 08:29 PM, Martin Nowak wrote:
> On Saturday, 21 December 2013 at 17:41:32 UTC, Timon Gehr wrote:
>> Adding a private symbol to an overload set can break 3rd party code
>> with these rules.
>
> Yes, this is understood, but it seems like a good tradeoff when compared
> to the alternative where overload resolution depends on look-up origin.
> The latter could easily break generic code and simple refactorings could
> introduce subtle bugs.
> ...

I think both options are similarly undesirable.

>> Since private symbols are usually excluded from di files I don't think
>> this design is viable.
>
> This, I don't have a good answer for, except that we have to put the
> private overload in the .di file as well.
>
>> I think it would be better to disallow overload sets with mixed
>> protection.
>
> Tried that, doesn't work. The most common counterexample is mixing
> private/public constructors.

You have a point there. :o)



More information about the Digitalmars-d mailing list