Hi,
I have a small question about SE-0028, "Modernizing Swift's Debugging
Identifiers"
https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md
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.
Regards,
Michael
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
