251–260 of 298 posts
Earlier quoted context omitted.
May be worth moving to rustc, because that's not just bad style, that's incorrect code.
I disagree, sometimes you end up building empty ranges in your code for valid reasons (as a result of math, for example). special casing a check on literals feels a bit like saying you can create an empty non-mutable vector.
Earlier quoted context omitted.
You can do that now. Its not quite the same but pretty close: fn f(n: Option ) -> u8 { match n { Some(n0) => n0, None => 10 } } fn main() { let n1 = f(Some(20)); let n2 = f(None); println!("{} {}", n1, n2); }
You're missing the point. Here's a good article that talks about the problems of having neither overloading nor default parameters, but in Go.[1] The problem is made significantly worse in Rust when all struct fields need to be initialized and there are no varargs. I really see no solution to the "stable API with more options" problem in Rust, aside from a builder pattern, which I really hate. 1: https://dave.cheney.…
I normally just leverage a couple of features: Derive(default) to have an "empty" initialized value and the struct field filling syntax
let x = Foo { field_i_care_about, ..Default::default() };Earlier quoted context omitted.
Not really a Rust programmer, but I would expect a Range of vectors to operate something like a vector of Ranges. So if you say [0,10]..[20, 30], the length would be twenty, and the elements would be [1,11], [2,12]... Presumably if there was asymmetry in the values like [1,10]..[20, 50] you'd end up with...something? Not really sure what it should be, there are lots of options!
The fact that there are options is my point: it's ambiguous. That's the reason there is no implementation for it in the std lib. You're absolutely free in Rust to define your own though.
But unlike the other complaints this one is still fixable, with zero backwards incompatibilities.
All we'd need is someone to implement that lint (in, say, clippy). What it'd need to do is look for `IntoIterator::into_iter(x)` calls expanded from `for` loops, where `x` is a variable of a `Copy` type. And maybe look for mentions of the same `x` after the loop.
EDIT: left a comment on the GitHub thread, I might be misremembering https://github.com/rust-lang/rfcs/issues/2848#issuecomment-6....
Earlier quoted context omitted.
It looks like you can't. You can create a Range out of it, but the range is not an iterator. If you look at the Range docs[0], you'll see that it only implements Iterator where its generic type (A) implements std::iter::Step. Going to the Step docs[1] you'll see that its only implemented by integer types and char. If Vec implemented Step, you could iterate over it. Also, if you're referring to the "contains" guessing…
That’s what I did (at repl.it anyway)... how do I print the values in a Range of Vectors?
Let's say I have the range [1].. [2], what is in this range?
Well vectors are sorted in lexicographic order, so every vector that starts with 1.
What comes after [1]?
Suppose it's any vector whose first non zero digit is in place n (e.g. n = 2 and the vector is [1, 0, 3, 1]). I can make a vector that comes earlier in the ordering by just inserting another 0 (e.g. [1, 0, 0, 3, 1]). This means that the vector has no non zero digit... but it is obvious that [1] doesn't come after [1], and that [1, 1] comes before [2] so [2] isn't the next vector, so (by proof by contradiction) there actually just isn't a well defined concept of next vector. As a result I definitely can't just list the vectors in a range in order.
Earlier quoted context omitted.
Whether 5..0 being an empty range is "bad stuff" or "good stuff" is a matter of perspective. It is often "good stuff" for me, when computing some indices to slice with. Panicking on construction would force one perspective on every use case.
But why isn't it panicking on len()? How is 0 the right answer there?
Honest question: Why is Rust preferred by trannies?
Range's idiosyncrasies and the antipathy to improving its ergonomics manifest in the issues raised against the project have been a capstone mental block to my investing emotionally in Rust. I continuously really want to like the language. The premise is good, a lot of the ideas are really compelling, but when it comes down to aspects I disagree with, I get a strong sense of Rust demanding that users subjugate themsel…
> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects I don't know why you feel that way. Any major language or standard library change goes through an RFC process, where anyone in the community can submit feedback, and from what I have seen, the official teams are very responsive to concerns.
- The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff dealing with situations where 'global allocation' is actively harmful, which, in addition to happening in kernel development, also happens when building managed runtimes.
- What comes across as an almost begrudging foreign-function interface, no ABI commitments, and lack of clarity about what is undefined behaviour under the `unsafe` operation needed to engage in any of this
- Cargo VS rustc and integration into other build systems. Sanctioned VS unsanctioned paths more generally.
- Prominent people in the community making comments about actively suppressing individual stylistic preferences because it's better for the collective
Earlier quoted context omitted.
Sure. But to solve those idiosyncrasies, you need to abandon backwards compatibility or introduce conflicting syntax.
Not necessarily. A new type could be introduced and the old one deprecated. Even without introducing a new type, it could be improved in a backwards compatible way. For example, derive the Copy trait, and add a contains method that takes an owned value instead of a reference (at least as long as the Idx type is Copy).
Here is the discussion
> In 2021 edition the compiler team could change the
meaning of (3..5) to resolve to a new type. Then if you wanted
the old type you have to request it by a fully qualified name
or something.
> That would be pretty awful. I think it would be
better to change IntoIterator and warn for differences
in copy and intoiterator in both editions so you can write portable code.