I think the author is really making a mountain out of a molehill here. As they say in the article, between the compiler and widely used tools like clippy there are multiple opportunities for developers to be gently warned to disarm their footguns.
That said, the article was an entertaining read and the blog is pleasantly styled. I’m glad I spent some time with this even though my ultimate takeaway is kind of “meh”.
Rust could just have mandated that const have to be uppercase and disallowed variables starting with uppercase. It would be better than making a warning.
Go has proven at this point that the language spec is the correct place to settle stupid bike sheding especially when they lead to misfeature like this one.
I understand that it’s not the most urgent thing to fix when it comes to Rust syntax but still a clear downside.
I mean if your why is related to having to hold shift or - gasp - using caps lock, I don’t know if I can’t assess the stupidity but I certainly don’t feel I’m clever enough to hold a conversation with you.
If you care about this rule, you can deny it on your projects (at the crate level or for individual items), but if it were an unconditional error then it would make things like FFI or following non-Rust naming conventions either annoying or impossible.
Yeah. The article is based on known bad patterns and, e.g you should never do use MyEnum::*;
and in other cases compiler gives warning. Are there people who do not want to understand the warnings and do not work in order to remove/suppress them?
I am working on an SDL project (not in Rust) and this example made the molehill seem slightly larger:
// whoops, accidentally commented out or deleted this import
// use crate::{SOME_GL_CONSTANT, OTHER_THING}
// uh oh!
match value {
SOME_GL_CONSTANT => ..,
OTHER_THING => ..,
_ => ..,
}
Specifically, I think FFI stuff or an initial Rust rewrite can be a strong incentive to (locally) disable compiler/linter warnings around capitalization because you are more interested in consistency with an existing C API. This turns the molehill into at least a real hill (though not a mountain).
// this is a common pattern in rust for one-line matches. If this thing matches Some(..)
// we can do something with the string.
if let Some(username) = maybe_username {
// so ok, this code will run if the username exists...
return username.to_uppercase();
}
// except, uh... Now that code will only run if 'username' matches Some("hey")
const username: &str = "hey";
As convenient as hoisting sometimes can be, I'm wary of it for exactly reasons like this. Even in "normal" code flow, it disrupts the usual linear flow of code logic when you're reading it, and this kind of action-at-a-distance makes it especially bad.
I was just about to comment that it's unfortunate that languages seem to have settled on the (false) dichotomy that enum variants should be either `MyEnumName.variantname` or just plain `variantname`. Often, you want enum variants to read almost like inbuilt literals, as that leads to more readable "natural-sounding" code than needing to say `MyEnumName.variantname` every time. However, having them actually be bareword literals leads to both ambiguity while reading and to long term maintainability issue like the one in the post. Postfix `.` may or may not be a great syntax specifically, but something like it still seems like a great compromise between these two extremes.
Do you know why the syntax was decided to get axed? Is this part of a larger PR where the decision is elaborated upon?
16 comments
[ 571 ms ] story [ 1458 ms ] threadThat said, the article was an entertaining read and the blog is pleasantly styled. I’m glad I spent some time with this even though my ultimate takeaway is kind of “meh”.
Go has proven at this point that the language spec is the correct place to settle stupid bike sheding especially when they lead to misfeature like this one.
I understand that it’s not the most urgent thing to fix when it comes to Rust syntax but still a clear downside.
That’s indeed the point.
Set up your highlighting tools so that they don't look the same. Problem solved.
https://github.com/rust-lang/rust/commit/04a2887f879
And here's a 2013 bug for the ambiguity:
https://github.com/rust-lang/rust/issues/10402
Do you know why the syntax was decided to get axed? Is this part of a larger PR where the decision is elaborated upon?