SE-0491: Module selectors for name disambiguation

Evolution Proposal Reviews
82

Please don’t put too much meaning in the names in my example. I just reused those from beccadax’s example to avoid having to invent something of my own… which I realize probably made a bad example because Swift::Unicode is implicitly imported everywhere, making things more awkward. Feel free to change the names to something else unrelated to the standard library:

import A
import B
import C

func render(using: A::View.B::BitmapRenderer) { ... }

Rephrased:

A future version of C could add View to the root namespace, or a future version of either A or C could add BitmapRenderer to A::View. So if someone is using automated tools to make things fully unambiguous (and thus minor-version-upgrade-proof), the above is what you’re likely to see in a source-stable library.

The probability of a conflict at the second level might seem minuscule, but semver does not really care about estimated probabilities, does it? How often a library maintainer is going to use :: will probably depends on the balance between how strictly they try to adhere to semver vs. how much of a hassle it is.

2 Likes
83

(Reposting from the previous pitch thread because it was still open and I got a notification about looking into that instead of this one- maybe the mods can help with that?)

My main concern about the current direction is that SomeClass.AModule:: may look very similar to SomeClass.ANamespace. where AModule and ANamespace are spelled the same. Maybe more importantly, it breaks reading left to right in increasing specificity. It might be possible to work around this with syntax highlighting in the editor, but just reading it as text I feel the need to have this new syntax scream more loudly at me.

There’s a lot of discussion about operator precedence and I do share some of the confusion raised. I also agree with a suggestion raised upstream (in the previous thread) that this syntax should look unclean and surprising.

Have we considered always requiring brackets on the bit being operated on? SomeClass.(AnotherModule::MyNamespace).doThing()?

FWIW in that scenario, anything after :: would have to be directly implemented in AnotherModule for the syntax to make sense to me. And I‘d „left-attach“ it such that MyNamespace must be implemented in AnotherModule, not „just“ the thing on the right-end of it. (This is the same as what’s currently proposed, just stricter due to the parens)

I did see @beccadax‘s comment about the parens looking like a function call, but I’m not convinced by that argument - there’s no function calls in Swift that are preceded by a dot, nor do they contain double colon syntax.

Again, maybe it’s all ok with appropriate syntax highlighting, but it doesn’t feel ideal to me as pitched.

Edit: I re-read some of the recent discussions in this thread and honestly this feature looks like it’s heading in a particularly bad direction. Is there a better way to deal with the problem being addressed here?

For example, what if the more specific import took precedent in the file it is imported in.

import A is not very specific, so if I import func B.myOverload then I would expect to get B‘s version, even if A also contains myOverload as well. I don’t think there’s anything wrong with getting specific in imports- in the worst case library authors wanting forwards compatibility will use more specific imports rather than the simpler option. If that proliferates throughout the ecosystem it’d be a much better outcome than ending up with :: everywhere due to devs being overly cautious or zealous.

1 Like
84

SE-0491 has been accepted; please see the new thread for a summary of the LSG's decision.

John McCall
Language Steering Group

6 Likes