SE-SNAKE.md

Eliminating Swift's Screaming Snake Case Identifiers

• Proposal: TBD
• Author(s): Erica Sadun
• Status: TBD
• Review manager: TBD

Revision 1.1

Introduction

This proposal aims to eliminate Swift's screaming snake case like __FILE__ and __FUNCTION__ and replacing instances with a common octothorpe-prefixed lower camel case #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

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.

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.

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)

Detailed design

This proposal:

• eliminates __FILE__, __LINE__, __FUNCTION__, and __COLUMN__
• introduces #sourceLocation, a compound type with well-defined fields that create a single context representation.

SR-198 requested the coalescing of the existing file, line, and function identifiers, potentially supporting a module representation as well. Andrew Bennett 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)"
    }
}

This proposal recommends adding support for module and sourceType fields (self.dynamicType, where available).

Alternatives Considered

Adding individual octothorpe-delineated identifiers for #file, #lineNumber, #function, and #column, and adding #sourceType and #module keywords. Using #lineNumber avoids conflict with #line, which already exists in the language.