[swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers

[Dany St-Amant]

> Le 27 janv. 2016 à 17:56, Erica Sadun via swift-evolution <swift-evolution at swift.org> a écrit :
> [..]
> This proposal renames the following identifiers:
> 
> __FILE__ -> #file
> __LINE__ -> #line
> __COLUMN__ -> #column
> __DSO_HANDLE__ -> #dso_handle
> This proposal eliminates __FUNCTION__. It introduces #symbol, (e.g. Swift.Dictionary.Init(x:Int,y:String)), which summarizes context including module, type, and function. 
> 
> A fully qualified symbol enables users to access exactly the information they desire. 
> It should contain parameter type information to properly identify member overloads.
> Each identifier will still expand at the call site, ensuring that the behavior matches that from the current suite.
> 
The fully qualified name could be quite long on occasion as I would expect it to include class hierarchy, nested class and nested function. So there might still be some usefulness in the brevity of a #function (__FUNCTION__). Revealing the fully qualified name is useful for fixing bug and understanding the code flow, but some people could see it as a security concern, as it reveal how your code is structured. 

On the brevity side, #file may benefit from a filename only version. I personally never liked seeing my user id in the output of __FILE__. On large project the filename only is not a perfect differentiator, but with __FUNCTION__ it is a nice starting point to find where the code reside ( find ./ -name FILE -exec grep -l FUNCTION {} \; ).

With the help of __LINE__, I start to even wonder if the calling signature (argument list) is even required as part of __FUNCTION__, but I don’t want to start long discussion on that topic, so I’ll drop the matter.

For #file, the user code can easily post-process the data and do an equivalent of basename(), but nonetheless the original __FILE__ has to be somewhere inside my final binary (and showing my user id)

For the #symbol, I do not think it would be that easy for user code to go extract the function name.

I think that keeping #function should be added to this proposal (assuming other support the idea).
And that the #shortfile (or whatever name) should be investigated later as a distinct proposal (again based on support for the idea).
The current proposal should only avoid preventing the possibility of providing a short file version in the future

Just for the record, I started to reply wanting a really long #symbol for the hierarchy and nesting, and convinced myself that I only needed the bare function name, file name and line number to find where a log was generated. On some rare case, I guess I might need the column number (like in the nice example from David)
> 
>  <https://gist.github.com/erica/8b8c7eb841da39ac47c7#implementation-notes>Implementation notes
> 
> Although the octothorpe-delineated #line identifier already exists in Swift for resetting line numbers (J. Lawrence), context can distinguish between uses. Joe Groff writes, "I'd prefer to use #line for this, and constrain the use of the current #line directive by context; like Chris said, we could require it to be the first thing after a newline, or we could adopt the #line = ... syntax a few people suggested. »

Using the #line = … syntax would need a reset syntax (#line = resume | default | real), which could make such implementation a little more complex than the simple wording above suggest, a note to that effect should be added to the proposal.

Dany St-Amant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/e269ffe4/attachment.html>