Workspace flags a unicode error in package reference

[TimothyMDean]

Description

I am getting flagged with a warning for the use of an obsolete - character (U+002D). I understand why these are coming up when found in my documentation comments. But this is happening in my Package.swift file:

The character U+002D is obsolete. Use a hyphen (‐), minus sign (−), dash (—), bullet (•) or range symbol (–). (unicode)
        .package(url: "https://github.com/vapor/fluent-sqlite.git", from: "3.0.0")

I have tried to replace the offending character with hyphens, em-dashes, and a couple of other variants. Unfortunately, changing the URL for an external package breaks my build. The fluent-sqlite.git repository cannot be found when I try to replace the existing U+002D character.

[SDGGiesbrecht]

It is impossible for Workspace to tell the difference between when a string literal represents text to display to a user and when it represents some sort of machine identifier like a URL. Workspace generally assumes the former, but provides escape hatches for the latter:

If you want to continue using the rule in general, either:

• You can use the escaped forms of the ASCII hyphen (\u{2D} in Swift string literals) when it needs to behave as a byte‐wise identifier instead of general text. (See Workspace’s own Package.swift for an example.)

• If there is some situation where escapes are impossible, you can put // @exempt(from: unicode) on the same line to ignore violations of that rule on that particular line. This kind of exemption also works for any other Workspace‐native rule. (For rules from SwiftLint, see its own documentation.)

If you really do not care for the rule at all, you can turn the entire rule off in the configuration:

let configuration = WorkspaceConfiguration()
configuration.proofreading.rules.remove(.unicode)

Does that answer your question?

[TimothyMDean]

Thanks for the clarification. I will use one of the workarounds you have suggested.

What would be really helpful for me is to have a way to exert a little more control over where this rule is applied. I understand that Workspace cannot tell the difference between string literal usage, but I can almost guarantee that my projects will almost never want this rule applied to any string literals because my use of String literals will generally not be for anything displayed to users. On the other hand, my documentation comments would absolutely be displayed as generated documentation, and so I like the idea of applying the rule there.

Is there any possibility of enabling the unicode rule for documentation comments but disabling it for string literals?

[SDGGiesbrecht]

No such functionality exists yet, sorry.

It is a very good idea though. It would be a beginner‐level thing to implement. The parser already knows the difference between token kinds, so that part should be no more difficult than adding a new if condition. The “hardest” part would be designing a configuration API for it.

If you are (or some future reader is) interested in taking it on, I can give you more specific directions.

[SDGGiesbrecht]

Closing. The question has been answered. The configurability idea has been moved to #261 where it can live in the issue title and be more discoverable.