Consider linting against 00B7 aka interpunct aka middle dot

[pnkfelix]

Code

#![allow(dead_code)]
#![deny(uncommon_codepoints)]
const COL·LECCIÓ: () = ();// This is Catalan

// The below is not allowed by the lexer today...
// const ·START: () = ();

// ... but this is allowed today ...
const MID·DLE: () = ();

// ... and this is also allowed today
const END·: () = ();


fn main() {
println!("{}", r#"
COL·LECCIÓ
·START
MID·DLE
END·
"#)
}

Current output

COL·LECCIÓ
·START
MID·DLE
END·

but note that visual of the first line is font-dependent, in terms of how the columns of a fixed-width font line up; the playpen collapses the L·L into a single glyph that occupies one character width.

Desired output

I'm not certain. I just want to make sure we follow-up on PR #120695

The options I see are either:

1. Leave things as they are (00B7 is hard-rejected as an initial character, and silently accepted in all other contexts)
2. Adopt something like what was proposed in PR uncommon_codepoints: lint against 00B7 MIDDLE DOT in final position #120695: continue hard-rejecting 00B7 as an initial character; lint against its occurrence as a final character, and silently accept it as a "medial" character
3. Something more aggressive than PR uncommon_codepoints: lint against 00B7 MIDDLE DOT in final position #120695, like linting against 00B7 in all contexts (except perhaps when it occurs in between two L's, to accommodate Catalan, as suggested by Manish here)
4. Other options? (We probably don't get any benefit from deviating far from Unicode committee recommendations, so we probably do not want to start accepting 00B7 as an initial character)

Rationale and extra context

No response

Other cases

No response

Rust Version

Stable channel

Build using the Stable version: 1.76.0

Anything else?

No response

[pnkfelix]

I think this is a T-lang issue to decide, not a T-compiler one.

@rustbot label: +T-lang -T-compiler

[pnkfelix]

Also I think its one that the Lang team might be able to resolve quickly, so I'm nominating for discussion at the T-lang triage meeting.

@rustbot label: I-lang-nominated

[Jules-Bertholet]

While we are at it, I think it could also make sense to lint against U+30FB KATAKANA MIDDLE DOT as mentioned here. MIDDLE DOT and KATAKANA MIDDLE DOT are the only two XID_Continue characters with Identifier_Type=Inclusion.. So maybe uncommon_codepoints should just check that?

[joshtriplett]

I'd be extremely hesitant to set any precedent of adding language-specific linting rules (e.g. only allowing this character between two Ls), but the idea of "lint on it at the end but not the middle" seems reasonable.

[tmandry]

I'd be extremely hesitant to set any precedent of adding language-specific linting rules

I think it's fine as long as we're reusing existing lint names. We don't make any guarantees about lints generally. It's seems more like a matter of how much code does the compiler team want to maintain.

[joshtriplett]

Based on discussion in today's @rust-lang/lang meeting, proposing that we not do this in uncommon_codepoints, and that we consider this again after we have the split-out lint that @Manishearth suggests in point 1 of #120228 (a lint about confusables with operator/punctuation).

@rfcbot postpone

[rfcbot]

Team member @joshtriplett has proposed to postpone this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.