Updated DIP22 - Private symbol visibility

[H. S. Teoh]

On Sat, Dec 21, 2013 at 10:09:44PM +0100, Martin Nowak wrote:
> On 12/21/2013 09:18 PM, Timon Gehr wrote:
> >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.
> 
> Mixed protection in overload sets are pretty rare.
> So we just need to find an acceptable solution to deal
> with them without breaking valid use-cases.
> I can hardly come up with any use-case but the constructor example
> though.

I was pretty upset when I encountered the following situation:

	---std/regex.d---
	...
	private struct Stack { ... }
	...

	---mymodule.d---
	...
	/* public */ struct Stack { ... }
	...

	---main.d---
	import std.regex;
	import mymodule;

	Stack s; // compile error: 'Stack' is ambiguous

I find it unacceptable that introducing a *private* symbol to std.regex
will break existing code (std.regex.Stack wasn't there in earlier
versions of Phobos). Since std.regex.Stack is private, why would it even
be in *any* overload set when compiling main.d??! This is leaky
abstraction at its best: changing the implementation of a module without
changing its API can randomly break user code due to newly-introduced
private symbols clashing with user-defined symbols.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX
swear at it. -- Pete Bleackley