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

[Jean-Daniel Dupas]

> Le 28 janv. 2016 à 05:26, Dany St-Amant via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> 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

I can't see a use case where you want to hide a part of the path in some files, and let it in other files, so having both #file and #shortFile don’t look that useful.

Maybe instead of having a #shortFile directive, we should consider adding a compiler flag to specify the project root, and just let the compiler expands the #file directive using a path relative to that root instead of the absolute path.


> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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