Updated DIP22 - Private symbol visibility

[Timon Gehr]

On 12/21/2013 10:14 PM, Martin Nowak wrote:
> On 12/21/2013 08:54 PM, Dicebot wrote:
>> On Saturday, 21 December 2013 at 19:29:28 UTC, Martin Nowak wrote:
>> Still don't understand how intended and expected behavior can be called
>> "bug".
>>
> If I make a refactoring and move a function from module A to B, but the
> function calls an overload set in A it should not have a different
> overload resolution.
> Similar case, if I pass an overload set via alias to a traits template
> in module B, the template should follow the same overload resolution.

Well, you pass an alias. Are you saying that for alias template 
arguments, the scope of the template declaration applies for 
accessibility checking? I.e. we cannot pass private symbols as alias 
arguments? I think this is an unreasonably high price to pay.

Note that if we actually allow this, having any kind of differing 
behaviour when accessing an overload set from different modules is a 
consistency issue, since the same template with an alias parameter might 
be instantiated from both modules with the same overload set.

> It's very important that we preserve these properties.
>
>> (I don't like updated DIP at all and will be against anything that puts
>> private symbols into overload sets)
>
> I don't like them either, but they have some use-cases.

Basically just the constructor thing though?
Note that constructors cannot be passed by alias due to a syntax 
restriction... :o)