Contextual keywords and type

[gaudecker]

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?

[stebalien]

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.

[aturon]

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.

[jimmycuadra]

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

[system]

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