No one writes production code right out of the gate. We all take shortcuts when we’re getting started. We don’t know what the right solution is going to look like. We probably don’t even know how to properly handle many of the error cases a new library presents us with. Or if we do, maybe we just want to make sure the happy-path works first.
For this reason I believe we should expose several semantic aliases in the standard library and language for expressing that what you’re looking at is not well-thought-out or production-ready.
Aliases for uncertain number types
Choosing the correct number type for the job is an important thing to do, but not necessarily something obvious when you’re just getting started out. If you see
foo: i32 or
foo: i64, is it clear that the integer type has been properly audited to fit the use-case, or has it just been chosen arbitrarily (possibly based on $COMPANY’s best-practices for defaults)?
I propose introducing
type int = i64 and
type float = f64 as types for a programmer to express “TODO: figure out appropriate integer type”. This would be accompanied by a
stub_number_types lint set to warn by default.
f64 are chosen because implicit widening would allow everything to be silently placed inside a stub type, and because it reduces the chances of running into an overflow while hashing out details. Yes, potentially covering up an overflow bug is a feature.
There is minor precedent for this in Jonathan Blow’s experimental Jai language, where
float are provided as aliases for exactly this purpose. Blow’s language is specifically designed for incremental, exploratory development and refactoring.
Aliases for assertion-style operations
If you see an
unwrap in a codebase, in can be there for two reasons: the author is certain that the operation succeeds, or the author was stubbing out some code and wasn’t ready to think about it. Unfortunately, with
unwrap it’s impossible to tell.
I propose introducing a
todo method as an alias for
unwrap. This would be accompanied by a
stub_assertions lint set to warn by default.
Conventions for unhandled patterns
If you see an
_ in a pattern or a
let _ =, it’s not clear if a catch-all or suppression is really intended, or if the author hasn’t properly considered all the possibilities.
I propose that
_todo be used as a convention for patterns that need more consideration before production. This would be accompanied by a
stub_patterns lint set to warn by default.
These are the 3 major semantic ambiguities that I’ve encountered while working with Rust, but I haven’t written that much non-toy code outside of std, so I’m willing to bet there are things I’ve missed.