Contextual keywords and type

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?

1 Like

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.

1 Like

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”.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.