[swift-evolution] [Pitch] Introducing #fileName debug identifier

[Erica Sadun]

Here is a small one as pitches go, but I think it embraces the spirit of the Groff (http://bit.ly/1pn47Yr <http://bit.ly/1pn47Yr>).

Of all the possible expansions brought up in the SE-0028 <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>  discussion on modernizing 
debug identifiers, I would get a lot of use out of `#fileName`  for my debug logging.
A simple websearch <https://www.google.com/?gws_rd=ssl#q=__FILE__+lastPathComponent> for `__FILE__ lastPathComponent` yields page after page of results
across both Swift and Objective-C.

My idea is that a `#fileName` debug identifier would return the file name and not the entire 
path for logging. Instead of 

`CoreError(reason: "Reason", context: "/Users/ericasadun/Desktop/SviftTestbed/SviftTestbed/main.swift:29") // #file, #line`

you'd be able to grab

`CoreError(reason: "Reason", context: "main.swift:29") // #fileName, #line`

all in native Swift without having to bridge to `NSString` or call `lastPathComponent`.

A bit of water has gone under the #identifier bridge since SE-0028, specifically a general embrace of
lowerCamelCase identifiers and unambiguous names. I think `#fileName` conforms to that
philosophy. 

(One might want to rename `#line` to `#lineNumber`, `#file` to `#filePath`, and `#column`
to `#fileColumn` but those lie outside the scope of this pitch.)

groffishly I hope,

-- E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160312/ef80349a/attachment.html>