[Pitch] Fixing member import visibility

[xwu (Xiaodi Wu)]

@tshortli

Do you have any examples or links to issues handy? I'm not familiar with the problems so I'll need to do some research. I did write some tests for operators declared as static members of an extension, but those tests appeared to demonstrate that operator lookup behaved the same as lookup for top level declarations. With and without this feature enabled, the operators were only considered in scope if the module defining them was imported. I wouldn't be surprised if there were more interesting operator test cases to consider, though.

It's been a while since I've thought about this topic, so admittedly my thinking about it is a bit jumbled. I was probably conflating @jrose's points #2 and #3 from way back when:

@jrose

Today's Swift is designed more like Java or C# or Python, in that if you import Bar in the implementation of Foo it doesn't affect clients who import Foo. Or, well, it doesn't make the top-level names of Bar visible to clients who import Foo.

1. You still need Bar around, because the compiler doesn't track whether you've used one of its types in Foo's public interface. (That's the previous section.)
2. Extensions in Bar are still made visible to clients who import Foo, because the compiler doesn't distinguish where extensions come from today.
3. Operator declarations in Bar are still made visible to clients who import Foo, because the compiler finds operators in a different way than it finds everything else at the top level.

We've addressed #1, of course, with visibility modifiers on import statements. It's fair to fix #2 alone without tackling #3, and probably good enough for these purposes that operators implemented as static members work consistently as you've verified. (That said, if ensuring that behavior involves tackling #3 more holistically, would be nice to get it all done.)