To my understanding Swift compile a project file by file, using the filename as an identifier to the file for the build process. The catch is one must use a different filename for each file otherwise he would get a
compile exception: "filenames are used to distinguish private declarations with the same name".
Picking a filename can be inconvenient / time-consuming sometimes and I've been wondering if the build process could use the complete file path as the identifier instead ?
We've talked about this in the past, but there are some tricky aspects to it. The first one is that you want builds to produce the same output (modulo debug info and #file) even when in a different directory; you can fix that by picking some base directory to store a relative path to. (For a package this might be the directory that contains the Package.swift.)
The second and more serious problem is that the file name slips into a program's ABI when a private type is archived using NSCoding. Foundation produces a warning at run time when this occurs, but we still don't want to inadvertantly lose user data by changing the runtime name of a type.
(Apart from lifting the filename uniqueness restriction, I've thought about this problem before because the way we encode the filename in private declarations isn't very efficient, and it would have been nice™ to change it to something shorter.)
Thank you for your quick reply.
I thought about the base directory trick that why I posted here thinking it can't be that simple. I didn't knew about the NSCoding issue indeed this seems not easily fixable.