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

Erica Sadun erica at ericasadun.com
Fri Jan 22 14:24:15 CST 2016


It could easily be replaced with #codeLine, #fileLine, etc.

-- E

> On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl at apple.com> wrote:
> 
> `#line` already exists in the language, how will you deal with this?
> 
> Jack
>> On Jan 22, 2016, at 12:17 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> https://gist.github.com/erica/016f44258586aaf13b5c <https://gist.github.com/erica/016f44258586aaf13b5c>
>> 
>> Feedback requested before I submit this as a formal pull request.
>> 
>> Thank you,
>> 
>> -- Erica
>> 
>> 
>> 
>> Eliminating Swift's Screaming Snake Case Identifiers
>> 
>> Proposal: TBD
>> Author(s): Erica Sadun <http://github.com/erica>
>> Status: TBD
>> Review manager: TBD
>>  <https://gist.github.com/erica/016f44258586aaf13b5c#introduction>Introduction
>> 
>> This proposal aims to eliminate Swift's screaming snake case <https://en.wikipedia.org/wiki/Snake_case> like __FILE__ and __FUNCTION__ and replacing instances with octothorpe-prefixed <https://en.wiktionary.org/wiki/octothorpe> lower camel case <https://en.wikipedia.org/wiki/CamelCase>, e.g. #file and #function. It extends the set of built-in identifiers and adds a generalized #sourceLocation representation.
>> 
>> The Swift-Evolution discussion of this topic took place in the "[Review] SE-0022: Referencing the Objective-C selector of a method" thread
>> 
>>  <https://gist.github.com/erica/016f44258586aaf13b5c#motivation>Motivation
>> 
>> Swift's pre-processor offers built-in __FILE__, __LINE__, __COLUMN__, and __FUNCTION__ identifiers. These expand to string and integer literals corresponding to a current location in source code. This feature provides high utility for logging, both tracing execution through logged messages and enabling developers to capture error context <http://ericasadun.com/2015/08/27/capturing-context-swiftlang/>.
>> 
>> The current identifiers owe their syntax to C's __FILE__ and __LINE__ macros. These are built into C's preprocessor and expanded before running the C-language parser. Swift's implementation differs from C's but offers similar functionality and, unfortunately, similar symbols. This proposal aims to break free of the historic chains of their unsightly screaming camel case, which look like boa constrictors trying to digest fully swallowed keywords.
>> 
>>  <https://gist.github.com/erica/016f44258586aaf13b5c#proposed-solution>Proposed solution
>> 
>> Using octothorpe-prefixed keywords offers several advantages:
>> 
>> They match the existing #available keyword (D. Gregor)
>> They match SE-0022's possible #selector(...) approach for referencing a method's Objective-C selector (D. Gregor)
>> They would support targeted code completion (D. Gregor)
>> They add a compiler-supported expression type that doesn't steal keywords, introducing a convention where # means "invoke compiler substitution logic here" (J. Rose)
>> They'd provide short-term solutions for a yet-as-undesigned macro system (D. Gregor)
>>  <https://gist.github.com/erica/016f44258586aaf13b5c#detailed-design>Detailed design
>> 
>> This proposal:
>> 
>> renames 
>> __FILE__ to #file,
>> __LINE__ to #line,
>> __FUNCTION__ to #function, and 
>> __COLUMN__ to #column
>> adds #module and #type to represent the source module, and the source type (self.dynamicType, should it exist) to extend the calling context semantics.
>> adds #sourceLocation, a compound type with well-defined fields that create a single context representation.
>> SR-198 <https://bugs.swift.org/browse/SR-198> requested the coalescing of the existing file, line, and function identifiers, potentially supporting a module representation as well. Andrew Bennett <https://bugs.swift.org/secure/ViewProfile.jspa?name=bnut> offered an initial design: 
>> 
>> public struct SourceLocation: CustomDebugStringConvertible {
>>     init(file: String = __FILE__, line: Int = __LINE__, column: Int = __COLUMN__, function: String = __FUNCTION__) {
>>         self.file = file
>>         self.line = line
>>         self.column = column
>>         self.function = function
>>     }
>> 
>>     public let file: String
>>     public let line: Int
>>     public let column: Int
>>     public let function: String
>> 
>>     public var debugDescription: String {
>>         return "\(function) @ \(file):\(line):\(column)"
>>     }
>> }
>>  <https://gist.github.com/erica/016f44258586aaf13b5c#alternatives-considered>Alternatives Considered
>> 
>> Given the narrow nature of this proposal, alternative approaches have not been seriously considered.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160122/2a830f39/attachment.html>


More information about the swift-evolution mailing list