As I've been dusting off some proposals, I've realized something:
#file is the wrong thing for us to be using to describe code context. We should be using
There are two main reasons that I've come up with to not use
#file frequently bloats the size of your binary. Every
#file usage results in a new
StaticString value that has to get encoded into a
__TEXT section of your binary. If your typical file-length path is 64 characters and you've got 128 paths in your binary, you're looking at 8KB of space just for file paths.
As a small example, I took a look at a small iOS app I've got on the store, and sure enough I have about a dozen KB of of my binaries taken up by paths. This is for a small app with a handful of screens. How much space would a larger app be wasting by encoding full path names?
2️⃣ Encoding paths into a binary is a security concern. It leaks details about the machine on which the binary was build and can expose information about the build process itself. For example, by examining the paths in the binary, you can make very educated guesses about the size of a development team and what sort of CI setup they have (if they have one at all).
Additionally, the elements in the paths themselves might be of concern. A folder might be named after a top-secret project, because that's the name of the tag or branch used to build the app, or it might be the code name of the project itself.
Apple employees need only look at your typical Apple rumors site to get an idea of the sort of information that can be discovered by running
strings on a binary.
I believe a far better value to be encoding into the binary would be the name (last path component) of the file. There is still a small chance of leaking sensitive information, but only if the file itself has a sensitive name. The binary size would be reduced, and we wouldn't be losing much meaningful information. Swift already disallows a single compilation target to have files with distinct paths have the same file name, so disambiguation isn't a huge issue.
Can we replace