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

Erica Sadun erica at ericasadun.com
Fri Jan 22 14:17:50 CST 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160122/9ebe26eb/attachment.html>


More information about the swift-evolution mailing list