[swift-evolution] [Proposal] Eliminating Swift's Screaming Snake Case Identifiers
Jessy Catterwaul
mr.jessy at gmail.com
Fri Jan 22 15:06:26 CST 2016
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 at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> It could easily be replaced with #codeLine, #fileLine, etc.
>>
>> -- E
>>
>>> On Jan 22, 2016, at 1:20 PM, Jack Lawrence <jackl at apple.com <mailto: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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> 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/37be915c/attachment.html>
More information about the swift-evolution
mailing list