Non ascii operators are rejected by identifier_name for not starting with a lowercase letter.

[ryanbooker]

While ["/", "=", "-", "+", "!", "*", "|", "^", "~", "?", ".", "%", "<", ">", "&"] are specifically allowed as the first character of operators, anything else is rejected.

e.g. using • as the compose operator or § as function application is relatively common and useful. Including them in allowed_symbols doesn't circumvent this behaviour. Should it? The isOperator function seems otherwise very narrow in its permissiveness.

I don't really want to disable the entire feature just to allow these functions.

[marcelofabri]

Including them in allowed_symbols doesn't circumvent this behaviour. Should it?

I think so.

---

Also, I think there's another bug in the implementation currently:

let containsAllowedSymbol = configuration.allowedSymbols.contains(where: name.contains)
                if !containsAllowedSymbol &&
                    !CharacterSet.alphanumerics.isSuperset(ofCharactersIn: name) 

This doesn't seem to guarantee that all non-alphanumeric characters in name are in configuration.allowedSymbols.

[ryanbooker]

OK. Cheers. I'll work on something for this in the next couple of days.

[dcutting]

Was there any progress on this? I'm trying to permit variables/functions that begin with underscores.

[SDGGiesbrecht]

@dcutting, this comment in the related pull request describes the current state of things.

[weakfl]

In #2134 @marcelofabri wrote:

SwiftLint started validating local variables with Xcode 9.3.

This has quite an impact on this issue, because now all local variables that start with an underscore are flagged as errors and since allowed_symbols does not work, there's no option to prevent this.

Also looks like a regression of #628, unless the default behaviour has been changed on purpose.

[mylemans]

We are running in the same issue.

[ryanbooker]

I don't think I ended up pushing anything. I got sidetracked onto work. :\

[Sajjon]

We are running in the same issue.

[endogenesis]

allowed_symbols not works for enum cases

[aklowther]

has anyone been able to give this attention?

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[colbad2]

Still an issue

[billburgess]

This seems like a huge issue that hasn't been fixed in over 5 years. What the heck?! It seems like allowing characters in your variable, types, etc is a huge oversight. This rule is unusable which means you can't even enforce simple length checks on variables.

[SimplyDanny]

The original issue has been fixed by supporting a new option additional_operators in the rule's configuration. Just add the symbols you want to have considered as operators to the list and the rule will keep silence on them.

Furthermore, the rule has completely been rewritten so that a few false positives or configuration issues should have been fixed as well. For anything more, that doesn't work as you expect, please create separate issues.