[Proposal] Eliminating Swift's Screaming Snake Case Identifiers


(Erica Sadun) #1

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.


(Jack Lawrence) #2

`#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@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #3

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

-- E

···

On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

It does?

-Chris

···

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

`#line` already exists in the language, how will you deal with this?


(Tino) #5

+1 for anything that removes underscores — those inherited from Haskell(?) are more than enough :wink:


(Erica Sadun) #6

And some other feedback off list:

- Why have individual keywords if they are subsumed into a common representation?
    I would not personally object to simplifying things without the extra keywords

- Eliminate #column entirely?
    No one I know ("Pauline Kael") uses it, but presumably it was designed in there for a reason

···

On Jan 22, 2016, at 1:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

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

-- E

On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jack Lawrence) #7

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

···

On Jan 22, 2016, at 1:39 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

`#line` already exists in the language, how will you deal with this?

It does?

-Chris


(Trent Nadeau) #8

+1 for improved consistency of the names and the "#" symbol in general.

···

On Fri, Jan 22, 2016 at 5:40 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

+1 for anything that removes underscores — those inherited from Haskell(?)
are more than enough :wink:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(David Owens II) #9

Getting rid of #column or __COLUMN__ seems extremely arbitrary; it’s very useful when providing debug output. Why would you remove it?

This is a trivial example, but you’d have no easy way to tell which err’ed:

func err(line: Int = __LINE__, column: Int = __COLUMN__) {
    print("err: \(line):\(column)")
}

if true { err() } else { err() }

The value of __LINE__ to #line is marginal. However, the collapse to a #sourceLocation structure of some sort that contained the info would be fantastic.

-David

···

On Jan 22, 2016, at 12:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

And some other feedback off list:

- Why have individual keywords if they are subsumed into a common representation?
    I would not personally object to simplifying things without the extra keywords

- Eliminate #column entirely?
    No one I know ("Pauline Kael") uses it, but presumably it was designed in there for a reason


(Chris Lattner) #10

FWIW, while I agree that there is no functional benefit to the renaming, I think that there is a pretty strong benefit to standardize the spelling of things. These were just a hold-over from C’s spelling, they were never actually thought through and debated.

-Chris

···

On Jan 22, 2016, at 1:08 PM, David Owens II via swift-evolution <swift-evolution@swift.org> wrote:

The value of __LINE__ to #line is marginal.


(Jordan Rose) #11

It's mainly used by LLDB to make sure user-visible line numbers make sense even in the presence of textually-inserted code.

Jordan

···

On Jan 22, 2016, at 13:43, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

On Jan 22, 2016, at 1:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`#line` already exists in the language, how will you deal with this?

It does?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jessy) #12

I think that having all of these individually accessible feels like global namespace pollution. Dot notated “properties” on “#sourceLocation” (or a similar word) should take care of everything we need, and be easier search for and learn about via autocomplete.

e.g.
#sourceLocation.module
#sourceLocation.function
etc.

That’s of course going with the idea that we would continue to type these things. I don’t actually feel like text is the appropriate representation, and would rather have icons in the code for something so reusable.

···

On Jan 22, 2016, at 3:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

And some other feedback off list:

- Why have individual keywords if they are subsumed into a common representation?
    I would not personally object to simplifying things without the extra keywords

- Eliminate #column entirely?
    No one I know ("Pauline Kael") uses it, but presumably it was designed in there for a reason

On Jan 22, 2016, at 1:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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

-- E

On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #13

Huh ok, I forgot we supported that. We could handle that by requiring that form of #line to be at the start of a line, if necessary.

-Chris

···

On Jan 22, 2016, at 1:43 PM, Jack Lawrence <jackl@apple.com> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal


(Jack Lawrence) #14

I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.

Jack

···

On Jan 22, 2016, at 1:48 PM, Jordan Rose <jordan_rose@apple.com> wrote:

It's mainly used by LLDB to make sure user-visible line numbers make sense even in the presence of textually-inserted code.

Jordan

On Jan 22, 2016, at 13:43, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

On Jan 22, 2016, at 1:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`#line` already exists in the language, how will you deal with this?

It does?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #15

Reload the gist: https://gist.github.com/erica/016f44258586aaf13b5c

Not sure what you mean by "icons in the code"

-- E

···

On Jan 22, 2016, at 2:06 PM, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> wrote:

I think that having all of these individually accessible feels like global namespace pollution. Dot notated “properties” on “#sourceLocation” (or a similar word) should take care of everything we need, and be easier search for and learn about via autocomplete.

e.g.
#sourceLocation.module
#sourceLocation.function
etc.

That’s of course going with the idea that we would continue to type these things. I don’t actually feel like text is the appropriate representation, and would rather have icons in the code for something so reusable.

On Jan 22, 2016, at 3:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

And some other feedback off list:

- Why have individual keywords if they are subsumed into a common representation?
    I would not personally object to simplifying things without the extra keywords

- Eliminate #column entirely?
    No one I know ("Pauline Kael") uses it, but presumably it was designed in there for a reason

On Jan 22, 2016, at 1:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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

-- E

On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #16

Pull request: https://github.com/apple/swift-evolution/pull/116

-- E

···

On Jan 22, 2016, at 5:40 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 22, 2016, at 1:43 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@apple.com>> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

Huh ok, I forgot we supported that. We could handle that by requiring that form of #line to be at the start of a line, if necessary.

-Chris


(Joe Groff) #17

Given the compiler-internal-ish nature of the existing `#line` feature (and since it's yet another thing copped from C with little consideration), I feel like we'd prefer to rename *that* if we had a better more mainstream use for the name #line.

-Joe

···

On Jan 22, 2016, at 2:04 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.


(Greg Titus) #18

You could make these identifiers act like {get set} vars in order to support the current behavior of #line. E.g. LLDB and playgrounds would use `#line = 12; #file = “foo.swift”` instead of `#line 12 foo.swift`.

  - Greg

···

On Jan 22, 2016, at 2:04 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.

Jack

On Jan 22, 2016, at 1:48 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

It's mainly used by LLDB to make sure user-visible line numbers make sense even in the presence of textually-inserted code.

Jordan

On Jan 22, 2016, at 13:43, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

On Jan 22, 2016, at 1:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`#line` already exists in the language, how will you deal with this?

It does?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #19

1. impressed.
2. gist revised: https://gist.github.com/erica/016f44258586aaf13b5c

-- E

···

On Jan 22, 2016, at 3:04 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

I also use it in a similar way in playgrounds to inject some hidden preamble code and then rewrite the location of diagnostics.

Jack

On Jan 22, 2016, at 1:48 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

It's mainly used by LLDB to make sure user-visible line numbers make sense even in the presence of textually-inserted code.

Jordan

On Jan 22, 2016, at 13:43, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

On Jan 22, 2016, at 1:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 22, 2016, at 12:20 PM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`#line` already exists in the language, how will you deal with this?

It does?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Remy Demarest) #20

+1 I love the idea of having not-only consistent naming convention for compiler-magic code starting with #.

And I also love the idea that source location would be one object that you can print to get the full story while still retaining the possibility to use each individual components as needed, which is probably the rarer case. I never find myself wanting only some of properties and usually don't include them simply because it takes longer to write the format properly, if I can get them all in one go it's certainly a win.

Remy Demarest
remy.demarest@gmail.com

···

Le 23 janv. 2016 à 18:46, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :

Pull request: https://github.com/apple/swift-evolution/pull/116

-- E

On Jan 22, 2016, at 5:40 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jan 22, 2016, at 1:43 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@apple.com>> wrote:

Indeed. Here’s the grammar from TSPL:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

Huh ok, I forgot we supported that. We could handle that by requiring that form of #line to be at the start of a line, if necessary.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution