Yo, back to Rust! Been using @cuviper's apostrophe hack (Allow Apostrophe In Names - #3 by cuviper) in C++ the past few months; am pretty sure it'd work in Rust too. Named returns is now the only thing I wish Rust also had... https://crates.io/crates/named_return exists, but seems like an unnecessary overkill when something as basic as this can and should be supported by the language natively. The crate-author's original rfc (Language feature: named returns · Issue #2638 · rust-lang/rfcs · GitHub) mentions how named returns can potentially shorten function names too:
For example, the HashMap's insert could, instead of:
pub fn insert(&mut self, k: K, v: V) -> Option<V>be:
pub fn insert(&mut self, k: K, v: V) -> _old_value: Option<V>(I think the documentation keeps being necessary, as it is today, in this particular case)
I think some functions may have longer names in the absence of this cosmetic feature. Let's say..
pub fn insert_and_also_returns_the_old_value(&mut self, k: K, v: V) -> Option<V>
Personally, I believe the whole point of OOP (which Rust does support the essense of) is dependency-inversion through interfaces; I believe it's impossible for humans to write code bottom-up, and instead much easier and effortless to design complex systems top-down instead. A level of indirection (the core of runtime polymorphic behavior) makes that possible. In the same spirit, "giving the programmer the ability to express themselves fully in code" should be the motto of Rust. If one doesn't detail what the return value(s) signify, months later, one could forget one's original intention when one's implementing those functions (trait functions, whatever). Much like how this little hack (or rather, neat little feature) enables the programmer to express in code their full intent of who/what they're expecting to be invoking the said function, and disabling other out-of-context uses of the function right at the compile time, while writing the declaration of the function outright! In English, if one were to document that, not only would it be many more words, but also one wouldn't actually be making any strides in actually developing the explained logic... One could document things in comments, but I believe that if writing detailed comments satisfies you, you're not gonna be making much progress in code; a good poetic programmer should document their visions in code (through high-level interfacing; traits; whatever), not in comments. An exception can be made for downright obvious one-liners, such as:
if (value < 0) {
...
}
else // value >= 0 {
...
}
Commenting return values would have totally satisfied me, but it seems the RLS-powered mouse-hover-tooltips trim down the in-line comments, destroying the whole point of the attempt.
Given
fn do_something() -> /*lucky_letter*/ char {
return 'a';
}
the tooltip upon hovering over its usage only shows
fn do_something() -> char
Sad.