Skip to content

Use backticks instead of single quotes in diagnostics #26499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

mdiep
Copy link
Contributor

@mdiep mdiep commented Aug 5, 2019

Looking through the diagnostics, I noticed some inconsistencies around whether 's or `s were used in diagnostics. AFAICT there wasn't a pattern to when one was used over the other.

This is an initial PR to convert to backticks. If accepted, I'll follow up with more PRs to convert to backticks. If rejected, I'd be happy to open a PR to remove backticks from existing diagnostics.

I prefer backticks here because:

  1. This matches quoting of code in Markdown, which I do often and almost unconsciously at this point
  2. Swift itself uses backticks to quote identifiers

@@ -4534,7 +4534,7 @@ WARNING(property_wrapper_wrapperValue,none,
"'projectedValue'; use of 'wrapperValue' is deprecated", ())
WARNING(property_wrapper_init_initialValue,none,
"property wrapper's `init(initialValue:)` should be renamed "
"to 'init(wrappedValue:)'; use of 'init(initialValue:)' is deprecated",
"to `init(wrappedValue:)`; use of `init(initialValue:)` is deprecated",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great example of the inconsistency: the same method was quoted with both backticks and single quotes within the same diagnostic.

@owenv
Copy link
Contributor

owenv commented Aug 6, 2019

FWIW, the diagnostics style document uses single quotes, and should be updated if a style change is made.

Personally, I prefer single quotes because I think they look a little nicer plain-text output, but I agree that either way the usage should be consistent! I'll let others weigh in on the backticks vs. quotes debate.

@xwu
Copy link
Collaborator

xwu commented Aug 7, 2019

In the diagnostics, single quotes are used around anything in code voice, which includes keywords.

Using backticks, while consistent with Markdown, could actually be confusing for users because enclosing a keyword in backticks has a different meaning in Swift—causing it not to be parsed as a keyword at all.

Consider the warning about defer blocks at the end of a scope: it tells users that the warning can be silenced by using a “‘do’ statement.” We want users to type do and not `do`.

@mdiep
Copy link
Contributor Author

mdiep commented Aug 7, 2019

I think the most important thing is to be consistent. But I find it unlikely that a user will be confused by `do` statement and not by 'do' statement.

@xwu
Copy link
Collaborator

xwu commented Aug 8, 2019

But I find it unlikely that a user will be confused by do statement and not by 'do' statement.

They can be equally confused by both, but one of these is potentially syntactically valid Swift with a meaning that’s unintended, and the other is syntactically invalid and diagnosed at compile time.

@CodaFi
Copy link
Contributor

CodaFi commented Dec 4, 2019

I err on the side of being consistent the opposite direction. The diagnostics style is mostly inherited from Clang, and Clang chooses single quotes to wrap identifiers. Could you please rebase this pull request and use single quotes instead?

@mdiep
Copy link
Contributor Author

mdiep commented Dec 5, 2019

I think Clang sets a low bar for diagnostics (despite being vastly superior to GCC in this regard). But I agree that consistency is most important. I'll try to find time to redo this.

@mdiep
Copy link
Contributor Author

mdiep commented Feb 18, 2020

Closing in favor of changing backticks to single quotes in #29895.

@mdiep mdiep closed this Feb 18, 2020
@mdiep mdiep deleted the use-backticks-in-diagnostics branch February 18, 2020 01:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants