51–60 of 119 posts
I wish they have used a different word than `const` for "not necessarily constant but it can be called at compile time". This is bound to confuse newcomers. Note this is unrelated to this release but I just realized how confusing it could be.
Earlier quoted context omitted.
TryInto is already implemented for slices in 1.47, so `let foo = u16::from_be_bytes(some_slice.try_into().unwrap());` would work before 1.48. This trait wasn't implemented for vectors though, so you would have to write `let foo = u16::from_be_bytes(some_vec.to_slice().try_into().unwrap());`. With new release you can drop `to_slice()` part. Nothing earth-shattering, but makes sense.
> TryInto is already implemented for slices in 1.47, so `let foo = u16::from_be_bytes(some_slice.try_into().unwrap());` would work before 1.48. Rustdocs say it was 1.36 even? https://doc.rust-lang.org/nightly/std/primitive.array.html#i...
I wish they have used a different word than `const` for "not necessarily constant but it can be called at compile time". This is bound to confuse newcomers. Note this is unrelated to this release but I just realized how confusing it could be.
Like `comptime` in Zig, I find that quite self-explanatory.
Earlier quoted context omitted.
I had to suffer with coworkers that would write doctests, bad docs and bad tests together at last! The solution here is to write real tests and hyperlink them in a marked up form to the functions they actually test. Coding inside of a doc string is an epic troll. This is a warning to anyone getting seduced by doctests, stay away! They invert the problem, when one should just write tests, it is a problem with the docu…
What is the distinction between a "real" test and a doc test that you're making? At least in Rust, they are the same thing.
Python's doctests are also formatted and in some ways behaving like an interactive shell session, with
>>> code here
output here
And of course on the flip side the best tests make for absolutely terrible examples since they try to exercise weird corner cases.
One of the things that made me so excited about Rust when I first used it was the capabilities of the Rustdoc system. The built in examples that are also unit tests, the ease of just using markdown... and now the linking is even simpler. It’s one of my favorite things about the language, and I think is why so many crates have such good documentation, because it’s easy to do. (and it’s tested and validated so you know…
Of course this is somewhat fickle and makes competing documentation generations harder to get started but as a user when rustdoc is really good it is a nice benifit.
Did I miss something or is there some progress being made in that respect?
Earlier quoted context omitted.
Like `comptime` in Zig, I find that quite self-explanatory.
const fns are not inherently evaluated at compile time, so that would be a misnomer.
Earlier quoted context omitted.
Go is the same. Everyone, including the stdlib maintainers seem to think a few lines of comments per method is the same as documentation on how to use the package, best practices, pitfalls, etc.
Java is the same as well
A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?