Allow more characters (like whitespaces and punctuations) for escaped identifiers

Evolution Pitches
42

It also supports top level classes by name no?

class Foo {}

print(_typeByName("Module.Foo")!) // Module.Foo
43

This feels unimportant and not worth the extra complication. Does not meet the threshold imv.

1 Like
44

Great. There were always some edge places where I needed the identifier to start with a number.

enum Dimension {
  case `1D`
  case `2D`
  case `3D`
  ...
}

enum Union3<A, B, C> {
  case `1`(A)
  case `2`(B)
  case `3`(C)
}
5 Likes
45

Hi Gwendal, thanks for bringing the topic of code and documentation generator!

I do agree that the proposal, as any change of the grammar, may have an effect on this type of programs and I want to share my reasons why I believe the impact may not be significant.

Most popular code, documentation generators or linters like Jazzy, Sourcery, SwiftLint and SourceDocs all use SourceKit under the hood.
Since back-ticks are currently considered (prior the proposal) as leading and trailing trivia it means that, if those tools currently support escaped identifiers they will automatically support the proposed change when updating SourceKit (update that may be required anyway for new Swift versions).
Do you have concrete examples of popular tools where this change does have an impact?

Related to HTML documentation security concern I find hard to see how this proposal can contribute to the issue.
Printing any methods, identifiers or comments should be already escaped as Swift already supports many characters outside the seven-bit ASCII that HTML supports without escaping. For example, characters like the < and > signs are, in fact, part of method declarations and they should be already escaped.
I went deeper and checked Jazzy implementation, as a result they do not have the mentioned issue: they either escape or wrap in a code tag the Swift declaration.
I am assuming other documentation generators may do the same.

I fully agree that we should be mindful on how a change may impact not only the language but the language environment too, so thanks for raising this and making me review the current state of Swift code and documentation generators.

2 Likes
46

That information is so out of date that when it actually was (sort of) true some people on this forum weren’t born yet. :wink:

But yes, as a former contributor to Jazzy and SwiftLint who went on to write in‐house replacements, this won’t make any significant difference to any such tools. In case you missed it, you also have the lead developer (@allevato) of Swift’s official formatter (swift-format) actively campaigning to have this added.

This would actually make things much easier. Right now I have about 200 lines of code just dedicated to producing valid identifiers. The ability to slap spaced grave accents on either end and use a file name as‐is would be so much simpler.

But the real reason I want it is that outside the English world, I’ve found that camel case just doesn’t always cut it and there is no legible solution without access to apostrophes, hyphens and other currently invalid joiners. French is one of the least problematic, but since I know at least one other person in this thread speaks it, I’ll use it for my examples. Which of the following uses the “right” style?

  • « aujourd’hui »

    • aujourdHui
    • aujourdhui
    • aujourd_Hui
    • aujourd_hui
    • aujourdeHui
    • `aujourd’hui`

  • « Faire quelque chose jusqu’à ce moment‐là. »

    • faireQuelqueChose(jusquÀ: ceMomentLĂ )
    • faireQuelqueChose(jusquĂ : ceMomentlĂ )
    • faireQuelqueChose(jusqu_À: ceMoment_LĂ )
    • faireQuelqueChose(jusqu_Ă : ceMoment_lĂ )
    • faireQuelqueChose(jusqueÀ: ceMomentLĂ )
    • faireQuelqueChose(jusqueÀ: ceMoment_LĂ )
    • faireQuelqueChose(`jusqu’à`: `ceMoment‐lĂ `)

To me, the currently valid ones all feel weird and are hard to choose between. But I would choose the last one in a heartbeat if it were available, especially if code completion can suggest it before the problematic character is typed, and can automatically place the accents on either side of the identifier.

8 Likes
47

But Swift is a language based on English. Why does it matter that its grammar and syntax fits poorly with other languages?

Do you also want to support localized versions of keywords, allowing arguments to be spelled before the function name, or adding argument labels after argument values?

48

The two that makes some sense to me are:

faireQuelqueChose(jusquÀ: ceMomentLà)

and

`faire quelque chose`(`jusqu’à`: `ce moment‐là`)

Either write it all camel-case or all "correctly". Mixing camel-case with apostrophes and dashes is the weird thing to do in my opinion. I'd rather just use camel-case like the rest of Swift. But that's just an opinion and we can all disagree on styling guidelines.

Apostrophes are weird because there are (at least) two of them you might use. Did you mean to use the straight one ' or the curved one ’? You used the typographically correct one above, but someone with a different keyboard configuration will use a straight one and it'll fail to match the function's name. Combine this with the necessary surrounding backticks and those identifiers are pretty inconvenient to type.

While not strictly related to the topic at hand, I'd also like to bring back the unsolved issue of characters not being normalized by the compiler. For instance, the Ă  above could be represented as either U+00E0 ('Ă ') or U+0061 U+0300 ('a' + combining grave accent), but the compiler will see the two representation as a different identifier despite being equivalent in Unicode. This is a similar issue to the apostrophe above, except that it's not even visible at all.

So maybe we'd need more than to compare using Unicode canonical equivalence if we are to accept apostrophes and other punctuation in identifiers. Think about 
 vs ... / - vs – vs — / " vs ” vs “.

3 Likes
49

While this would be independently nice to have, I think it's best to separate it from the discussion of this pitch. There are a number of blocking technical issues which prevent implementing unicode normalization for identifiers in the compiler anytime soon. It will likely involve dropping the standard library's ICU dependency in favor of sharing a slimmed down version of the data files between the compiler and stdlib, which would be a large effort.

2 Likes
50

-1
I expect most people who think this is a terrible idea are keeping quiet to avoid getting flamed (certainly that's what the reactions in a local Slack dev group suggests), so I guess I'll have to speak up.

Escaped identifiers are a drag to parse visually and increasing their occurrence in code would make code look worse.

The example from the proposed solution looks terrible and I'd personally hate to work with code like this. Save prose for comments.

51

Do you believe there are no use cases where readability is enhanced? If not, why should we be afraid that developers will abuse the ability? It should be left to policy, not limitations in the parser.

1 Like
52

LOL. Human nature and history suggest that it's not about "fear" but about seeing the patterns during the last 30 years of software engineering. Plenty of bad code out there. Think custom operators and operator overloading in C++ 
 lot of scary bad code resulted.

I admit that I haven't run into as much bad emoji in identifiers and operators as I feared might appear, so maybe it won't be as bad as it could be


I don't see any gain of significance. I can maybe see a slight interest in the testing context, but really not that much and I wouldn't want to have to deal with a test file full of tests with crazy long identifiers and back ticks all over the place (ones like the quote in my post). Just too darn ugly.

There are likely to be many consequences that we regret, seems to me. Here's a simple one: when we want to quote code in markdown it'll be like ``My Crazy Routine Name - the one I really like, you know?() so much punctuation noise
.

anyway.

53

Maybe we should move to the review thread (SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers) now that it is up.

1 Like
54

Didn't realize that. Thank you. Moved my -1 to that. Someone who has the permissions necessary to edit the proposal at the top could maybe add a link to the review thread to make it obvious that there is one now and direct people to it.

55

Thanks for the suggestion, I edited the original post to include the link to the proposal review.

1 Like