Proposal to eliminate Screaming Snake Case from Swift

[erica]

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 and then in its own "[Proposal] Eliminating Swift's Screaming Snake Case Identifiers" thread

[lattner]

Please change the title to something more understandable, drop the images, and squash the commits. Thanks!

Also, what are the pro's and con's of #sourcelocation producing a struct vs a tuple?

FWIW, I think that my concerns about how default args are implemented is overblown. Particularly if we went with a tuple representation, I don't see a problem with this.

[erica]

Tuples are just anonymous structs. I don't care, so long as there are labels. How about

(module: String, file: String, line: Int, column: Int, function: String, parentType: String)

-- E, googling "Squashing" -- but I'll probably delete the repo, and reload sans pics.

On Jan 25, 2016, at 11:58 PM, Chris Lattner notifications@github.com wrote:

Please change the title to something more understandable, drop the images, and squash the commits. Thanks!

Also, what are the pro's and con's of #sourcelocation producing a struct vs a tuple?

FWIW, I think that my concerns about how default args are implemented is overblown. Particularly if we went with a tuple representation, I don't see a problem with this.

—
Reply to this email directly or view it on GitHub #116 (comment).

[austinzheng]

Squashing is sort of complicated but you can also use git reset --soft HEAD^, where the number of '^'s is the number of commits you want to back
out of. Then all the changes that were in those commits will instead be in
staging, and you can just make a new commit.

Hope that helps,
Austin

On Tue, Jan 26, 2016 at 11:59 AM, Erica Sadun notifications@github.com
wrote:

Tuples are just anonymous structs. I don't care, so long as there are
labels. How about

(module: String, file: String, line: Int, column: Int, function: String,
parentType: String)

-- E, googling "Squashing" -- but I'll probably delete the repo, and
reload sans pics.

On Jan 25, 2016, at 11:58 PM, Chris Lattner notifications@github.com
wrote:

Please change the title to something more understandable, drop the
images, and squash the commits. Thanks!

Also, what are the pro's and con's of #sourcelocation producing a struct
vs a tuple?

FWIW, I think that my concerns about how default args are implemented is
overblown. Particularly if we went with a tuple representation, I don't see
a problem with this.

—
Reply to this email directly or view it on GitHub <
https://github.com/apple/swift-evolution/pull/116#issuecomment-174861672>.

—
Reply to this email directly or view it on GitHub
#116 (comment)
.

[lattner]

I'd suggest:
(file: String, line: Int, column: Int, symbol: String)

Where symbol would be the fully qualified name like "Swift.Dictionary.init".

[DougGregor]

We should bring this discussion back to the mailing list. I think using a tuple is a terrible idea :)

[erica]

What do you think of:

#file, #lineNumber, #column, #symbol (e.g. Swift.Dictionary.init), #module, #contextDictionary

and calling it a day?

• using contextDictionary allows expandability and can subsume all existing context elements, indexed presumably by the same names
• renaming function to symbol takes care of self.dynamicType as well
• file and lineNumbers are gimmes
• column is apparently well liked by some (not going to kick someone's dog on this)
• adding module fills a big hole.

No tuples for Doug, covers some of Chris's points.

-- E

On Jan 26, 2016, at 2:31 PM, Doug Gregor notifications@github.com wrote:

We should bring this discussion back to the mailing list. I think using a tuple is a terrible idea :)

—
Reply to this email directly or view it on GitHub #116 (comment).

[lattner]

One other thing, please add to the proposal:
DSO_HANDLE --> #dso_handle

[lattner]

ugh, DSO_HANDLE also has squished snakes around it.

[erica]

Will do. Also d'erp on not seeing that Module was subsumed into symbol. Will fix that too.

-- E

On Jan 27, 2016, at 12:02 AM, Chris Lattner notifications@github.com wrote:

One other thing, please add to the proposal:
DSO_HANDLE --> #dso_handle

—
Reply to this email directly or view it on GitHub #116 (comment).

[erica]

Doug and I need to talk about this more. I’m leaning toward a direction of just having #line/#file/etc available as scalars, he prefers a single #sourcelocation concept of some sort. I’d like for he and I to get on the same page before the proposal goes farther if that is ok.

-Chris

On Jan 27, 2016, at 8:47 AM, Erica Sadun erica@ericasadun.com wrote:

Will do. Also d'erp on not seeing that Module was subsumed into symbol. Will fix that too.

[lattner]

Huh, apparently I am impersonating @erica now. That last comment was from me.

[jessesquires]

This PR was replaced by #123

Just a quick note for documentation. 😄