221–230 of 298 posts
I actually love this type. Specifically because you can build ranges over complex key types. For example, two keys in a BTreeMap can be used to define a range selector to collect items out of the map, it made me very happy to be able to do this: https://github.com/bluejekyll/trust-dns/blob/main/crates/ser...
Earlier quoted context omitted.
Honestly it feels more like they make a lot of 40% solutions.
Well, as others have said: Hitting exactly 80% is pretty much impossible. And we've established that hitting more than 80% produces languages that are often bad, in some way or another. So, logically it follows: aim for less than 80%. You can always add things; you can't take things away.
Earlier quoted context omitted.
The problem is that his/her proposal also says that start Now consider the usability nightmare `(1..10).unwrap()` would be and `&slice[(1..10).unwrap()]` and `(1..10).and_then(|range| slice.get(range))` instead of `slice.get(1..10)`. That's the actual problem, not that `Range` implements iterator. Oh and most ranges are used ad-hoc (created and then directly consumed) so for many use cases going with Range + IntoIter…
> The problem is that his/her proposal … Please just use the word “their”. “his/her” is not just awkward but also not even inclusive, as there are many people who do not use “his” or “her” pronouns.
Also, fix the problem that Range can't do .len(): fn main() { let r = 0u64 .. 1; let n = r.len(); | ^^^ method not found in std::ops::Range println!("Hello, world! {}", n); } https://play.rust-lang.org/?version=stable&mode=debug&editio...
Interesting: .len() is not the length of a slice induced by the range or the distance between start and end but instead it's the len method form `ExactSizedIterator`, which in turn is a "special case" of where `Iterator.size_hint()` is known to return a correct value. The thing is `Iterator.size_hint()` does return a size, which is usize. So `Range ` can only implement `ExactSizedIterator` on 64-bit targets, which I…
In some Rust forums, the language designers were shocked to learn that this is possible.
At any rate, the Range type was very clearly designed for slices of in-memory contiguous arrays. Then template magic was used to make them "generic over all types". So now we have a situation where Range acts like an array subset and a B-Tree range selector, and a source for ordinals in iteration, and a bunch of other things. Some of which are incompatible.
Earlier quoted context omitted.
The problems with Range are well-understood by now, so I don't think that it would be too much of a stretch to argue that a brand-new type could be added to the stdlib with some variation on the semantics given at the end of the post. However, transitioning the dedicated range syntax to that new type would be the tricky part.
Deprecate two-dot syntax, introduce three-dot syntax? /s
Earlier quoted context omitted.
Deprecate two-dot syntax, introduce three-dot syntax? /s
Funnily enough, there was a ... syntax for inclusive ranges, but because when looking at code at a glance it is hard to distinguish between .. and ..., it was replaced with the current syntax: ..=
I feel like this is an example of what Jonathan Blow calls a "Big Idea" or a "100% solution". His thesis is that when you make a feature of a language too abstract and usable in many different contexts, eventually there will be so many corner cases that the result will almost certainly be clunky and full of footguns. He claims that language designers should aim for "80% solutions" instead, which cover most common usa…
This is crazy, but I kind of like the way web does new features. They start off with a name that obviously will never be needed (eg "moz-blur") and work with that for a while until it becomes apparent what "blur" should be. If the rust developers had named "Range" as "RustRange" or something else weird to start with, then they could come back through later and name it to the more desirable name. This seems like a goo…
Earlier quoted context omitted.
> The problem is that his/her proposal … Please just use the word “their”. “his/her” is not just awkward but also not even inclusive, as there are many people who do not use “his” or “her” pronouns.
It's sad how many cumulative hours have been lost to policing language just because some <1% of the population decided to treat their pronouns like a fashion accessory that must be as unique as possible.
Earlier quoted context omitted.
> The problem is that his/her proposal … Please just use the word “their”. “his/her” is not just awkward but also not even inclusive, as there are many people who do not use “his” or “her” pronouns.
It's sad how many cumulative hours have been lost to policing language just because some <1% of the population decided to treat their pronouns like a fashion accessory that must be as unique as possible.
Earlier quoted context omitted.
> obviously not ranges, only to return values indicating the range is malformed? It's not the case. The only think affected by range being generic is that `contains` takes a reference instead of a copy (which btw. can likely be eliminated by the optimizer). Which is necessary to allow thinks like `Range `. All other things have nothing to do with it being generic but with for which use cases it was designed for. In t…
But shouldn't len() panic instead of returning 0? I don't even understand how it could return 0 without having already done all the work to determine it should have returned a negative number.