Hello, Swift community!
The review of SE-0513: API to get the path to the current executable ended on March 4th, 2026.
Feedback on the proposal was mostly positive in terms of the underlying functionality, and discussion focused primarily on the specific return type of the API and its behavior on different platforms.
As currently written, the proposal makes the API unavailable on platforms where it is not or cannot be implemented, specifically Embedded and WASM. Other failure cases, like a dynamic failure to retrieve the path on a platform where the operation is otherwise supported, are represented by the property evaluating to nil.
The language steering group feels that this distinction makes it more difficult to write cross-platform libraries, because the client must match their usage of this API to the same compiler conditions that make it available. Furthermore, contributors to Swift's WASM support commented that some WASM environments have a reasonable implementation for this property. If they were added, Embedded would be the only language mode remaining where the API is unavailable.
The language steering group believes that we cannot make this broad of an assumption on behalf of all possible embedded environments; there may certainly be embedded environments where there is a reasonable implementation of this operation. In some future where platform-specific operations like the one proposed here are better abstracted out of the standard library, we can imagine that those environments could easily provide that implementation as part of their Swift runtime hooks.
Regarding the return type, the API pitched here uses String in its return type at a time when the FilePath type is also in pitch. The language steering group accepts in principle that this API is a very valuable addition, but we also agree with the author who stated during review that "[i]f there were such a [FilePath] type, it would definitely change the calculus here." We believe that if FilePath already existed, it would be the obviously correct choice and we would not want a String version of this API to also be present.
For these reasons, we return this proposal for revision so that the authors can update the API to be unconditionally available on all platforms (returning nil where it is not supported) and so that they can can coordinate as needed with the FilePath proposal so that they can update this API to use that type.
Thanks to everybody who participated in the review!
—Tony Allevato, review manager