Now that the Pandora’s box has
been opened, I would like to open discussion about contextualizing the
type-keyword.
Not being able to use type as a variable or a field name has been a huge
pet-peeve of mine. Dealing with “types” in programming is really common, and
personally I have encountered this issue on most Rust projects I have started.
Alternatives that have been given to me suggest using “kind”, or the ridiculous
"typ" or “type_”. These alternatives just don’t cut it for me, and make reading
code needlessly difficult.
Would contextualizing the type-keyword lead to any backwards compatibility issues?
Does the Rust-community have any interest in this?
Actually, I’d like to go the other way and lint (default allow) against using (most) contextual keywords as variable/function names anywhere. Otherwise, you’re asking the programmer and the syntax highlighter to infer whether or not something is a keyword based on the current context.
My kneejerk reaction is similar to @stebalien’s: I think that contextual keywords are seen as a necessary wart to provide backwards compatibility, but should be effectively thought of as keywords, especially for new code – for exactly the reasons @stebalien mentions.
I share the frustration of OP, but I think it’s workable to keep “type” as a universal keyword. The way I handle this is by changing the identifier/field/whatever to describe what the value is a type of. For example, in ruma-events, all the structs which represent Matrix events have a “type” field, which I renamed “event_type”, but use a Serde annotation to have it converted back to “type” when serializing to JSON. I find this satisfactory as it doesn’t change the semantics of the name and it doesn’t resort to ugly hacks like “typ”.