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

[Erica Sadun]

As someone who has custom code in her error contextualization code for trimming file name's last component, I thoroughly understand the desire for short file. I would be happy to add it in.

The fully qualified name is left as an exercise for Apple, but I will update the proposal to include that concern, so it's there and ready for discussion.

I hear what you are saying about decomposing #symbol and will add that concern to the proposal.

-- Erica


> On Jan 27, 2016, at 9:26 PM, Dany St-Amant <dsa.mls at icloud.com> wrote:
> 
> 
>> Le 27 janv. 2016 à 17:56, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto: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/20160128/93626985/attachment.html>