Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My least favorite Rust type

ridiculousfish.com

Post reply on HN
Print view View original

261–270 of 298 posts

Re: My least favorite Rust type

#261

Post by silon42 »

hobofan wrote: post #7
adamnemecek wrote: post #4

I wouldn't call it a wart, these things have been debated pretty extensively.

Just because it has been debated extensively doesn't mean it's not a wart. Having run into the "reverse range does not contain what you obviously expect it to contain" before and wasting a few hours on it, like many other people have and will continue to do in the future, definitely makes me want to call it a wart.

IMO, the current behavior is correct, it would be absolutely horrible when having lower bound higher bound suddenly reversed the order instead of producing an empty result. (think dynamic ranges, not hardcoded ones). Perhaps the operator should be .>>., not .. as an improvement.

Re: My least favorite Rust type

#262

Post by om2 »

bilkow wrote: post #160
WhyNott wrote: post #6

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…

I don't think Range is intended to be a 100% solution at all. It only supports iteration over integers and slice indexing over a specific integer size, which are its main use cases. Also the author is exaggerating on the footgun, as Range is explicitly end-exclusive, and the Regex is explicitly end-inclusive (e.g. [a-z] includes z), so a RangeInclusive should be a straightforward decision. Yes, I think it was a rushe…

The footgun is not just the exclusivity but the fact that `RangeInclusive` has an extra bool field and so is wastefully large for use cases that need the inclusivity. i.e. it's a perf footgun.

Re: My least favorite Rust type

#263

Post by pwdisswordfish4 »

saagarjha wrote: post #172
ccccc0 wrote: post #163

Earlier quoted context omitted.

If you ever create a BTreeSet , it will use String's PartialOrd, which is directly #[derive]d from Vec .

I have nothing against String having PartialOrd. I don't see why this means Vec should be PartialOrd–especially because treating a String as a Vec sounds very wrong.

Why does it sound wrong? Since strings are UTF-8, this just boils down to lexicographical ordering of code points.

Ironically though, that should be actually more objectionable than ordering arrays by lexicographical order of elements, because the underlying code point order is pretty much useless for any other purpose than having some arbitrary deterministic order. Meaningfully ordering strings is an inherently locale-dependent operation, and PartialOrd has no way to take this into account.

Re: My least favorite Rust type

#266

Post by fluffything »

ShroudedNight wrote: post #173

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…

> Range's idiosyncrasies and the antipathy to improving its ergonomics

Can you point us to where this antipathy was displayed?

Re: My least favorite Rust type

#267

Post by fluffything »

bugmen0t wrote: post #265

If Range doesn't require PardialOrd, I'm not sure I know what Range is at all...

I don't even know what PartialOrd and PartialEq even are, mathematically speaking...

The docs about these feel written by someone who knew that "some API like this" would be a good idea, but that somehow never managed to flesh out what these traits should semantically imply.

Which is kind of dumb, given that there was _excellent_ prior art about this when Rust was created (Elements of Programming, From mathematics to generic programming, the C++ standard library and the dozen papers about operator, ...).

And that's one of the things I dislike more about rust. The way to overload operators, like +, or Which is why, e.g., the standard library implements "Add" for strings. That doesn't mean that it implements "Addition" for strings, but rather that it overloads the Plus operator. And in the String case it does so to implement "Concatenation".

Which is IMO super dumb, because they could have just fixed this by naming the `Add` trait `Plus` instead, which is what languages that do the same thing, like C++, already do (`std::plus`, `operator+`, ....).

You could argue that using `+` to implement concatenation is "bad", but it is way less worse than using "Addition" to implement concatenation, which is what Rust ends up requiring everybody to do because that's just how you overload the `+` operation.

Re: My least favorite Rust type

#268

Post by setr »

javajosh wrote: post #210
leshow wrote: post #121

Earlier quoted context omitted.

There are plenty of hurdles in Rust, but I wouldn't call this one of them. What exactly do you expect an Iterator for a range of vectors to do?

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!

This seems like you'd very quickly end up with a mess of arbitrary heuristics falling over itself with seemingly mundane changes, ala excel

Re: My least favorite Rust type

#270

Post by matklad »

ridiculous_fish wrote: post #201
dathinab wrote: post #185

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…

Author here. In my idea, x..y would be like x+y: not fallible, but may panic. There would be a separate fallible function for creating ranges, analogous to checked_add. (Of course unlike x+y, x..y would require checks in release builds too.)

Agree with you that there won't be any problems with panicking in this setup.

Although, it'll require some non-minor api adjustments: at the moment, Range's fields are public. To maintain the invariant, we would have to make them private and provide getters. Which we actually already do for RangeInclusive, because of that extra bool field. Which is an inconsistent mess :)

Post reply on HN