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)
