3 ms·
! might be "less" punctuation than [[ noreturn ]] but is a lot harder to google. And why do you need the "->"? That is just more line noise.
by petschge 7y ago
! might be "less" punctuation than [[ noreturn ]] but is a lot harder to google. And why do you need the "->"? That is just more line noise.
- gpm 7y agoBecause `fn foo() u8 {}` doesn't read as nicely as `fn foo() -> u8 {}`? Also because "no return type" is the most common return type, and this way representing "no return type" as omitting the `-> ()` reads nicely: `fn foo() {}`
- lone_haxx0r 7y agoIn my opinion, "u8 foo() {}" looks and reads better than both of those.
- gen220 7y agoI’d agree that it looks better in isolation. I think that the advantage of leading with `fn` arrives when you have paragraphs of functions to scan through. Leading with a consistent word (be it fn, func, or whatever) immediately and disambiguously identifies the line as defining a function (rather than a variable, or whatever), which is a useful landmark to anchor on or pivot from.
- umanwizard 7y agoSo, using grep or a similar tool, how would you find the definition of the function, separately from its uses? In a Rust codebase I could just run `grep -r "fn foo" .` and find the definition immediately. Clearly this doesn’t matter if you’re in an IDE with a working “find definition” feature, but that’s often enough not the case that I find easily greppable definitions to be a gigantic advantage.
- jcelerier 7y agocome on, C++ IDEs had "go to definition" features for literal decades
- umanwizard 7y agoIn what way does this contradict my comment?
- the_why_of_y 7y agoBut it comes at a cost: this is the reason why struct declarations need to end with "};" in C.
- andrewshadura 7y agoThey could have used : similar to what Pascal and Kotlin do.
- steveklabnik 7y agoWe could have, and discussed it, but IIRC there's some good reasons why we didn't. That was a very long time ago and I don't quite remember them now, though... I think that the idea is that this gets ambiguous with type ascription?
- estebank 7y agoI'm not sure of the historical context, but it would have required either for the syntax to declare the return type of closures to be different from functions or for type ascription to have a different syntax. To be honest, type ascription being : was a (small) mistake that affects the comprehensibility of errors because it is distance 1 from multiple common typos and is valid almost everywhere in the grammar, so it is very easy for the parser to go down the wrong route. Even worse, the feature is nightly only so we're not even getting the benefits of the simple syntax. Advice for language designers: make your grammar redundant, with lots of sign posts for the compiler to recover when things are wrong. Things like mandatory semicolons are good for both humans when reading code and for the compiler when parsing it. You can also make your compiler perform semicolon autoinsertion, but still have an error, that way the type checker can still run.
- steveklabnik 7y agoYou don’t need to google, you just need to click: https://doc.rust-lang.org/stable/book/appendix-02-operators.html https://doc.rust-lang.org/stable/book/appendix-02-operators.... In theory, punctuation is noise. In practice, it helps you understand the parts of a sentence. Same with code.
- petschge 7y ago8 pages of punctuation. So clear and easy to read.
- deleted 7y ago[deleted]
- adrianN 7y agoNot that much more than in C++: https://en.cppreference.com/w/cpp/language/expressions#Operators https://en.cppreference.com/w/cpp/language/expressions#Opera...
- squiggleblaz 7y agoWhy is =* MulAssign etc overridable but = (assignment) not overridable?
- adwn 7y agoOne reason is that overriding "=" would allow you to violate the move semantics of Rust: a = b; is guaranteed to be equivalent to memcpy(&b, &a, sizeof(a)). In C++, you can overload the assignment operator, which lets you do crazy, unexpected things. In the end, it's mostly a tradeoff between convenience (writing a = b; instead of a.assign_from(b);) and explicitness (being able to tell what might and what might not happen under the hood).
- zozbot234 7y agoIt's the difference between the Copy and Clone traits. One thing that Rust still lacks in its standard library is a Clone-like trait for moving data, which is also something that C++ can express, and could be useful in combination with "pinned" object which can't be memcpy'd. There is a crate providing this (via a Transfer trait), but it's nowhere near being a standard.