<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This was already brought up on list. See: <b class="">[Pitch] Introducing #fileName debug identifier. </b><span style="font-family: Palatino-Roman;" class="">Module-relative path seems to be most highly requested form of #file. </span><span style="font-family: Palatino-Roman;" class="">Chris Lattner had the final word, </span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="font-family: Palatino-Roman;" class="">"</span><span style="font-family: Palatino-Roman;" class="">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. "</span></div></blockquote><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><font face="Palatino-Roman" class="">To my best understanding this was the end of the discussion, leaving two loose threads:</font></div><div class=""><span style="font-family: Palatino-Roman;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1. Actually introducing the change, which I'm not sure if it needs a bug report or what</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2. Gregorizing the #function literal to match the new method/function naming scheme</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">-- E</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 11, 2016, at 3:48 PM, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">I have a small question about SE-0028, "Modernizing Swift's Debugging Identifiers"<br class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md</a><br class=""><br class="">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__.<br class=""><br class="">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.)<br class=""><br class="">Another alternative would be to make "#file.lastPathComponent" a debugging-identifier that is handled by the preprocessor, so we could write something like<br class=""><br class=""> func myLog(msg: String, filename: String = #file.lastPathComponent, line: Int = #line) { ... }<br class=""><br class="">and the preprocessor would optimize away the call to lastPathComponent, so that the lastPathComponent function doesn't have to be called at runtime.<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>