# SE-0491: Module selectors for name disambiguation

**URL:** <https://forums.swift.org/t/se-0491-module-selectors-for-name-disambiguation/82124>\
**Category:** Proposal Reviews\
**Created:** [September 13, 2025, 11:31pm UTC](https://forums.swift.org/t/se-0491-module-selectors-for-name-disambiguation/82124 "2025-09-13T23:31:33Z")\
**Posts on this page:** 1\
**Showing post:** 73

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 30, 2025, 5:55pm UTC](https://forums.swift.org/t/se-0491-module-selectors-for-name-disambiguation/82124/73 "2025-09-30T17:55:02Z")

</div>

> [@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](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0491-module-selectors.md#use-a-syntax-that-avoids-s-shortcomings), 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:

> [@\[Pitch\] Stat types for Swift System](https://forums.swift.org/t/pitch-stat-types-for-swift-system/81616/13):
>
> 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.

---

_[View the full topic](https://forums.swift.org/t/se-0491-module-selectors-for-name-disambiguation/82124)._