# Why can't the same filename be used twice **URL:** \ **Category:** Using Swift\ **Tags:** packagemanager\ **Created:** [February 2, 2024, 10:11am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791 "2024-02-02T10:11:21Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Vaida12345](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vaida12345/32/33857_2.png) [@Vaida12345](https://forums.swift.org/u/Vaida12345)\ **Post date:** [February 2, 2024, 10:11am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/1 "2024-02-02T10:11:21Z")
Hello, Just wondering why we can't have the same filename in two different folders. Something like this won't compile: ```swift folder 1/file.swift folder 2/file.swift ``` There was a note, _Filenames are used to distinguish private declarations with the same name_, but I suppose maybe it can use the relative paths to the project? ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [February 2, 2024, 10:33am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/2 "2024-02-02T10:33:25Z")
If that restriction could be lifted I would be glad, my filenanes tend to just contain their directory structure as a prefix/suffix. ---
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [February 2, 2024, 10:35am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/3 "2024-02-02T10:35:24Z")
This isn't a compiler restriction and is not related to compiler features in any way, as far as I know. Would you mind filing an issue for it on this page? [Issues · apple/swift-package-manager · GitHub](https://github.com/apple/swift-package-manager/issues) ---
**Author:** ![Vaida12345](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vaida12345/32/33857_2.png) [@Vaida12345](https://forums.swift.org/u/Vaida12345)\ **Post date:** [February 2, 2024, 10:36am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/4 "2024-02-02T10:36:44Z")
Of course, thanks Max! ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [February 2, 2024, 2:08pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/5 "2024-02-02T14:08:56Z")
> [@Max\_Desiatov](#): > > This isn't a compiler restriction and is not related to compiler features in any way, as far as I know. Yes, this is a language/compiler limitation, not just SPM: [swift/lib/Driver/Driver.cpp at c89f63ff278b9c3f3082eeb2f301d92850c9088e · apple/swift · GitHub](https://github.com/apple/swift/blob/c89f63ff278b9c3f3082eeb2f301d92850c9088e/lib/Driver/Driver.cpp#L954-L961) The main issue with ideas like "paths relative to the project" is that the compiler has no notion of a "project". It just takes a list of files from the command line and processes them, and they could be located anywhere on the filesystem. The closest thing is has is the current working directory (either inferred or passed via `-working-directory`). But even then, there's nothing that prevents it from accepting files that are outside of that directory. There's probably a solution here, but it's more complex than it seems at first because it's easy to imagine situations where just moving a source file without making any other changes to its content could change a bunch of the generated symbols, which is a problem for build caching. Today, only a file's content, its basename, and the module name contribute to the names of those symbols. ---
**Author:** ![Vaida12345](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vaida12345/32/33857_2.png) [@Vaida12345](https://forums.swift.org/u/Vaida12345)\ **Post date:** [February 2, 2024, 2:13pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/7 "2024-02-02T14:13:30Z")
I see, thanks for the detailed explanation ---
**Author:** ![jlukas](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jlukas/32/317_2.png) [@jlukas](https://forums.swift.org/u/jlukas)\ **Post date:** [February 2, 2024, 2:57pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/8 "2024-02-02T14:57:43Z")
> [@allevato](#): > > There's probably a solution here, but it's more complex than it seems at first because it's easy to imagine situations where just moving a source file without making any other changes to its content could change a bunch of the generated symbols, which is a problem for build caching. Today, only a file's content, its basename, and the module name contribute to the names of those symbols. Is this actually a problem? Since the filename is only used for symbols that are private to the file, it seems like the symbols changing couldn’t change the semantic result. ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [February 2, 2024, 3:33pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/9 "2024-02-02T15:33:24Z")
The semantic result isn't all that matters; build systems might see that the output has changed and perform unnecessary rebuilds of downstream dependencies. As a general principle, it's always a good idea to reduce the amount of external state that can affect the output of your build. ---
**Author:** ![jlukas](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jlukas/32/317_2.png) [@jlukas](https://forums.swift.org/u/jlukas)\ **Post date:** [February 2, 2024, 3:35pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/10 "2024-02-02T15:35:31Z")
So you’re worried about doing unnecessary rebuilds, rather than missing necessary rebuilds? Apologies for misunderstanding. ---
**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\ **Post date:** [February 2, 2024, 4:01pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/11 "2024-02-02T16:01:13Z")
Perhaps a minor problem but still: same named files will have the same `#fileID`. ---
**Author:** ![nicksloan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nicksloan/32/35193_2.png) [@nicksloan](https://forums.swift.org/u/nicksloan)\ **Post date:** [July 3, 2025, 6:11am UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/12 "2025-07-03T06:11:38Z")
It really feels preposterous that this issue isn’t a higher priority. This is the kind of thing that if I knew about before I learned Swift, I would have assumed Swift was not worth learning. It ought to be embarrassing for people, but when my work is embarrassing to me I try to fix it. I’ve made a proposal [on the SPM issue](https://github.com/swiftlang/swift-package-manager/issues/8811) that is probably really dumb, at least for the #fileID reason mentioned, and I’m more than happy to hear about why it won’t work, but the intellectual dishonesty of saying there is nothing that can be done is pretty hard to take. It seems to me that there are multiple paths to fixing this, and everyone would rather make it someone else’s problem. ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [July 3, 2025, 2:39pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/13 "2025-07-03T14:39:26Z")
The fact I've played with more than a dozen languages and build systems, with Swift being the only one I've seen with that issue so far, also adds to the feeling of dishonesty. ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [July 3, 2025, 4:50pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/14 "2025-07-03T16:50:17Z")
This one is Past Jordan’s fault and I’m very sorry, but also it means the present stewards of Swift need to be very careful changing things: > **[Swift Mangling Regret: Private Discriminators](https://belkadan.com/blog/2021/11/Swift-Mangling-Regret-Private-Discriminators/?tag=swift-regrets)** > > Sometimes the proof-of-concept ends up being the forever implementation. ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [July 3, 2025, 5:35pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/15 "2025-07-03T17:35:42Z")
While I don't think this is a _major issue_ (pretty much nothing forces you to use specific file names), I also have a minor dislike when tooling forces specific and (seemingly) arbitrary restrictions on file organization. It's the same reason I bristle when people suggest things like a `folderprivate` access level, because there's no such thing as a "folder" as far as the compiler is concerned. I could imagine something like this working: a new flag like `-source-root-directory` and the strings used for private discrimination could be the relative paths from that root instead of just the basename. Build systems could then pass a relevant root directory that guarantees uniqueness for any source files that it can reach for a particular compilation: SwiftPM could pass the package root, Bazel could pass the workspace root, etc. There are still some interactions I haven't thought all the way through (what would `#fileID` evaluate to? Build systems would still need to be able to disambiguate outputs like `.o` files). ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [July 3, 2025, 5:45pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/16 "2025-07-03T17:45:17Z")
> [@allevato](#): > > There are still some interactions I haven't thought all the way through (what would `#fileID` evaluate to? Build systems would still need to be able to disambiguate outputs like `.o` files). Could build systems pass a per-module root? That way `#fileID` would be in the form `ModuleName/Path/To/FileName.swift`. ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [July 3, 2025, 5:49pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/17 "2025-07-03T17:49:34Z")
That would sort of defeat one of the key features of `#fileID` over the old `#file/#filePath`, which is that it wouldn't leak details of your build machine's file system structure in the resulting binary. Not as severe as showing the full absolute path, but it could still be a security concern. ---
**Author:** ![Lancelotbronner](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lancelotbronner/32/22071_2.png) [@Lancelotbronner](https://forums.swift.org/u/Lancelotbronner)\ **Post date:** [July 3, 2025, 6:05pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/18 "2025-07-03T18:05:31Z")
I agree that leaking absolute paths is certainly not a good idea as it can reveal critical information. I don't see how a module-relative path could be exploited? Maybe a flag to tune the behaviour of `#fileID`? That way you could choose a strategy of either (I imagine) `complete secrecy`, `leak filenames` or `leak module path` and you'd only "pay for what you use"? For the mangling issue with ABI-minded libraries, wasn't there an attribute that allowed specifying the specific mangled name you wanted? ---
**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:** [July 3, 2025, 11:59pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/19 "2025-07-03T23:59:42Z")
> [@allevato](#): > > That would sort of defeat one of the key features of `#fileID` I don't entirely believe this as a "key feature". `#fileID`'s [documentation details](https://developer.apple.com/documentation/swift/fileid()) such a potentially possible module disambiguation, so such a concern probably isn't novel and, arguably, properly resilient tooling would have taken this into account. Regardless, I think the community/ecosystem would benefit far better from same file names - even at the small cost of breaking changes for some tooling. ---
**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\ **Post date:** [July 4, 2025, 2:17pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/20 "2025-07-04T14:17:54Z")
Perhaps it's possible to make it a "breaking change" only if there are same-named files involved? So it won't actually break anything as the same-named file situation is currently impossible. ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [July 4, 2025, 5:44pm UTC](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791/21 "2025-07-04T17:44:01Z")
Can still lead to very subtle errors. What if you have three files with the same name, and then over time delete one, and then another? [Next page](https://forums.swift.org/t/why-cant-the-same-filename-be-used-twice/69791.md?page=2)