[swift-evolution] SE-0028 Debugging Identifier #filename

Michael Peternell michael.peternell at gmx.at
Mon Apr 11 16:48:42 CDT 2016


I have a small question about SE-0028, "Modernizing Swift's Debugging Identifiers"

I think this is a great feature, because I think it makes it clearer that there a special syntactic rules involved when the debug-identifier is written as "#file" instead of __FILE__.

Will "#filename" also be included in Swift 3.0? It's basically the same as #file.lastPathComponent, but with the additional safety feature that you cannot find the full pathnames when analyzing the executable file. I saw it mentioned in the proposal, but I'm not sure if it was accepted, or if it is just an idea for some later Swift version. I think the idea is great. I think adding #filename would be an improvement. In the past, when writing Objective-C, I used the __FILE__ macro quite a few times, usually for writing logging macros. And in the function that gets called eventually, I always strip away all but the last path component (using strrchr()). ("#file" should stay, I'm not suggesting that it is replaced with "#filename", I only suggest that "#filename" be added.)

Another alternative would be to make "#file.lastPathComponent" a debugging-identifier that is handled by the preprocessor, so we could write something like

    func myLog(msg: String, filename: String = #file.lastPathComponent, line: Int = #line) { ... }

and the preprocessor would optimize away the call to lastPathComponent, so that the lastPathComponent function doesn't have to be called at runtime.


More information about the swift-evolution mailing list