Why can't the same filename be used twice

Hello,
Just wondering why we can't have the same filename in two different folders. Something like this won't compile:

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?

If that restriction could be lifted I would be glad, my filenanes tend to just contain their directory structure as a prefix/suffix.

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

Of course, thanks Max!

1 Like

Yes, this is a language/compiler limitation, not just SPM: swift/lib/Driver/Driver.cpp at c89f63ff278b9c3f3082eeb2f301d92850c9088e · apple/swift · GitHub

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.

4 Likes

I see, thanks for the detailed explanation

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.

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.

So you’re worried about doing unnecessary rebuilds, rather than missing necessary rebuilds? Apologies for misunderstanding.

Perhaps a minor problem but still: same named files will have the same #fileID.