Updated DIP22 - Private symbol visibility

[Martin Nowak]

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.

> 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.