Pippin
(Ethan Pippin)
February 28, 2025, 10:46pm
44
Swift doesn't have fully qualified name lookup and disambiguation with modules is questionable. If we introduce the struct Subprocess
later, we are shooting ourselves in the foot.
While I personally don't have a strong opinion on either, using current disambiguation techniques cannot be a tangible solution to an "official" API.
What would be really cool is if in the future we could typealias
(funcalias
?) the run
for those who really don't want that Subprocess.
typealias run = Subprocess.run
opened 02:00PM - 08 Mar 16 UTC
bug
compiler
| | |
|------------------|-----------------|…
|Previous ID | SR-898 |
|Radar | rdar://problem/19481048 |
|Original Reporter | mkadijk (JIRA User) |
|Type | Bug |
<details>
<summary>Environment</summary>
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81) / Xcode Version 7.2.1 (7C1002) / iOS 9.2
</details>
<details>
<summary>Additional Detail from JIRA</summary>
| | |
|------------------|-----------------|
|Votes | 18 |
|Component/s | Compiler |
|Labels | Bug |
|Assignee | None |
|Priority | Medium |
md5: ea3a4fb46f14a67b99d4cb07142d5803
</details>
**blocks**:
* [SR-14195](https://bugs.swift.org/browse/SR-14195) Swift emits an invalid module interface when a public type has the same name as a module
**is duplicated by**:
* [SR-1386](https://bugs.swift.org/browse/SR-1386) Can't reference a type inside a module that has a type whose name is the same as the module
* [SR-1389](https://bugs.swift.org/browse/SR-1389) Types in modules cannot be uniquely referenced if a type and module have the same name.
* [SR-4801](https://bugs.swift.org/browse/SR-4801) Name resolution problem for packages with same-named data types
* [SR-5110](https://bugs.swift.org/browse/SR-5110) Name collision not solved with namespacing
* [SR-6705](https://bugs.swift.org/browse/SR-6705) Symbol with the name of the module overrides module namespace
* [SR-7909](https://bugs.swift.org/browse/SR-7909) Module type namespace collision
* [SR-12647](https://bugs.swift.org/browse/SR-12647) Error in parsing module interface when class have the same name with the framework
**Issue Description:**
Given two modules with the same type, where one module has a type that has the same name as the module itself with generic parameters it will become impossible to explicitly refer to the type you want.
### Example
**Module A:**
``` java
struct NoError: ErrorType {}
```
**Module B:**
``` java
struct B<T> {}
struct NoError: ErrorType {}
```
**The app:**
``` java
import A
import B
let ambiguousError: NoError // This correctly errors because it's ambiguous
let errorA: A.NoError // This correctly works since we make the module explicit
let errorB: B.NoError // This _incorrectly_ errors, complaining about required arguments
```
### Expected behaviour
Only `ambiguousError` should give an error, the other two error constants should work since the module is specified to prevent ambiguous type errors.
### What happend instead
The error we get with `B.NoError` is `Reference to generic type 'B' requires arguments in <...>`. The compiler incorrectly assumes we are referring to `struct B` instead of the module B. This makes it impossible to fix the ambiguity.
### Workaround
It is possible to work around this by creating a `typealias` in a *seperate* file where we only import module B and there `typealias BNoError = NoError` then we can use the `BNoError` as the type of `let errorB` to work around the issue.
Swift's name lookup is…messy. Very messy. This causes a number of problems, and today I'd like to talk about a potential solution for one of them.
Swift allows names to be shadowed by declarations in a nested scope. The idea is that, if you import WidgetKit to access its Widget type, but you yourself declare a Widget type, you can always access WidgetKit's version by writing WidgetKit.Widget. But what if something shadows the name WidgetKit? Then you can't fully qualify the names in WidgetKit a…
1 Like