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
<SE-SNAKE.md · GitHub
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
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.
<SE-SNAKE.md · GitHub 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)
<SE-SNAKE.md · GitHub 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 <Issues · apple/swift-issues · GitHub; requested the coalescing of the existing file, line, and function identifiers, potentially supporting a module representation as well. Andrew Bennett <Issues · apple/swift · GitHub; 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)"
}
}
<SE-SNAKE.md · GitHub Considered
Given the narrow nature of this proposal, alternative approaches have not been seriously considered.