This was already brought up on list. See: [Pitch] Introducing #fileName debug
identifier. Module-relative path seems to be most highly requested form of
#file. Chris Lattner had the final word,
"In this case, I don’t think that more is better. Having too many options and
knobs is not good for anyone. Having #file produce the module-relative path
(including the module name) serves all of the use-cases that I’m aware of,
since you can further slice and dice it to get the base file name out. "
To my best understanding this was the end of the discussion, leaving two loose
threads:
1. Actually introducing the change, which I'm not sure if it needs a
bug report or what
2. Gregorizing the #function literal to match the new method/function
naming scheme
-- E
> On Apr 11, 2016, at 3:48 PM, Michael Peternell via swift-evolution
> <[email protected]> wrote:
>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
