SE-0491: Module selectors for name disambiguation

[xwu (Xiaodi Wu)]

@TheHarcker

My only nit-picky concern is the precedence rules when :: is used on a member type. This is also shortly discussed in the Alternatives Considered section, though in a slightly different form.

Specifically, in one of the examples ‘Spacecraft.IonThruster::Engine’, is parsed as ‘Spacecraft.(IonThruster::Engine)‘, though it seems more natural when reading the code, to parse it as ‘(Spacecraft.IonThruster)::Engine‘, as that is how operators are generally applied in Swift.

Indeed, there is an ongoing conversation which highlights a very practical pitfall related to this issue:

@Michael_Ilseman

I feel that FileStat would be the better name for the struct. System.Stat (which is used to resolve shadowing a name that’s very likely to be shadowed) implies the status of the system instead of a file.

Similarly, FileSystemStat if you get around to statfs.

Another even nicer looking alternative is File.Stat and FileSystem.Stat, but that requires a File namespace that we might not want to introduce in System. Should such a namespace exist in the future, I’d recommend adding type aliases.

With the proposed feature as it is, Michael's preferred spelling would end up allowing us to write File.System::Stat to mean FileStat rather than FileSystemStat. That is to say, the very problem that Michael is trying to avoid by a deliberate naming choice ("System.Stat implies the status of the system instead of a file") would be undermined.

Mind you, this namespacing practice already has precedent in the standard library: we have decided to put a bunch of APIs under the Unicode namespace, such as Unicode.Encoding. The ability to use an unparenthesized module qualifier for any nested component interrupts the intended straight-through reading: Unicode.Swift::Encoding reads like it's a Swift encoding rather than a Unicode encoding. In some places, that reading is merely nonsensical and not actually confusing, but in others (such as the File.Stat example above) it would be a dealbreaker.

Going forward, unparenthesized module qualifiers would require authors to consider how nested types will be read with any combination of module prefixes, making current namespacing practices probably unwise--which admittedly would advance the goal of not having ambiguous nested types in clashing modules, but not exactly in the way proposal authors intend.