# \[Review, 3rd\] SF-0007: Subprocess

**URL:** <https://forums.swift.org/t/review-3rd-sf-0007-subprocess/78078>\
**Category:** Foundation\
**Created:** [February 25, 2025, 1:07am UTC](https://forums.swift.org/t/review-3rd-sf-0007-subprocess/78078 "2025-02-25T01:07:00Z")\
**Posts on this page:** 1\
**Showing post:** 44

<div class="post-metadata">

**Author:** ![Pippin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pippin/32/24826_2.png) [@Pippin](https://forums.swift.org/u/Pippin)\
**Post date:** [February 28, 2025, 10:46pm UTC](https://forums.swift.org/t/review-3rd-sf-0007-subprocess/78078/44 "2025-02-28T22:46:09Z")

</div>

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.`

```swift
typealias run = Subprocess.run

```

> <https://github.com/swiftlang/swift/issues/43510>
>
> | | |
> |------------------|-----------------|…
> |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.

> [@Pitch: Fully qualified name syntax](https://forums.swift.org/t/pitch-fully-qualified-name-syntax/28482):
>
> 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…

---

_[View the full topic](https://forums.swift.org/t/review-3rd-sf-0007-subprocess/78078)._