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

281–290 of 298 posts

Re: My least favorite Rust type

#281

Post by timClicks »

carlmr wrote: post #275
coolreader18 wrote: post #214

Earlier quoted context omitted.

> I get a strong sense of Rust demanding that users subjugate themselves to all the choices and opinions of the architects [..] I don't really get where you're coming from here, especially with regards to this issue -- it seems like almost everyone, including Rust core team members, agree that `impl Iterator for Range` was an API design mistake, that came out of (IIRC) Iterator existing prior to IntoIterator in the p…

>This seems to me to just be an unfixable design flaw due to backwards-compatibility rules This sounds like something that could be solved in the next edition.

How?

Re: My least favorite Rust type

#282

Post by andy_ppp »

kibwen wrote: post #233
andy_ppp wrote: post #179

Earlier quoted context omitted.

That’s what I did (at repl.it anyway)... how do I print the values in a Range of Vectors?

The range doesn't have values. A range defined by Rust has a start point and an end point, and no other semantics. Some additional functions then add behavior if the types contained in the range can be compared via greater-than, etc. Vecs in Rust can be compared if their contents can be compared. For a range of two vecs, foo and bar, to ask if a third vec is "contained" in that range is to ask if it compares greater…

Okay thanks for the explanation!

Re: My least favorite Rust type

#283

Post by floatboth »

timClicks wrote: post #281
carlmr wrote: post #275

Earlier quoted context omitted.

>This seems to me to just be an unfixable design flaw due to backwards-compatibility rules This sounds like something that could be solved in the next edition.

How?

Make the (x..y) syntax construct some std::BetterRange for code in a new edition.

Re: My least favorite Rust type

#284

Post by sacado2 »

yodelshady wrote: post #279
sacado2 wrote: post #277

The worse bug I fought in one of my rust programs was when using the range type. I needed to go from n to 1 included, so, from n included to 0 excluded. Of course `(n..0)` didn't work, so I tried `(0..n).rev()`, which didn't work either (first, you generate all numbers in [0;n-1], then you reverse the list), and I can't blame the language, it makes sense, but it's highly unintuitive (in python for instance, `range(n,…

I think (1..=n).rev() will do what you want? A .step_by() that accepts negative values a la python would be nice, but I can live without. I'd love a REPL for this sort of thing though - a website just isn't as good.

Thank you! I didn't know about the `=n` syntax.

Re: My least favorite Rust type

#285

Post by jswizzy »

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…

I've always seen Rust as a transitional language like SmallTalk or ALGOL. It's a glance into the future of programming and the Next era of modern languages but probably not the next 40 year language itself.

Re: My least favorite Rust type

#286

Post by xondono »

fluffything wrote: post #267
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…

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

They are binary relations, just some that are more "niche" than the more common ones. PartialEq actually has a link to it's mathematical definition on the docs [0].

[0]:https://en.wikipedia.org/wiki/Partial_equivalence_relation

Re: My least favorite Rust type

#287

Post by bluejekyll »

djur wrote: post #221
bluejekyll wrote: post #25

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...

Seems to me that you could still have this syntactic sugar if you use a separate type for iterable ranges and non-iterable bounds and then have them both implement RangeBounds.

I think you’d still want something where all the types Barrow to something consistent type. Otherwise, PartialEq/PartialOrd becomes complex to reason about. I haven’t tried this, but maybe the Idx of Range could be Borrow, much like the get requirements on HashMap.

Re: My least favorite Rust type

#288

Post by fluffything »

xondono wrote: post #286
fluffything wrote: post #267

Earlier quoted context omitted.

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…

> I don't even know what PartialOrd and PartialEq even are, mathematically speaking... They are binary relations, just some that are more "niche" than the more common ones. PartialEq actually has a link to it's mathematical definition on the docs [0]. [0]: https://en.wikipedia.org/wiki/Partial_equivalence_relation

> They are binary relations,

Thanks for making my point: this API provides _a_ binary relation is IMO useless. There are millions of binary relations that one could implement for a type, and often many that make sense implementing for a particular type, and that this API doesn't support (e.g. there are both strict partial order and total orders for float in the IEEE standard; this API however implements none).

For this to be useful, the docs would at least need to say what can one assume about the partial order implemented by PartialOrd (is it strict? is it non-strict? something else?), and ideally have a solid ordering hierarchy so that APIs and algorithms can pick what makes sense to them, instead of having to assume the lowest-possible denominator imaginable, which results in, e.g., it not making sense to implement ordering for floats in the standard library, even though to be IEEE compliant it would actually need to do that.

Re: My least favorite Rust type

#289

Post by centimeter »

tsimionescu wrote: post #206
centimeter wrote: post #171

Earlier quoted context omitted.

Haskell’s Foldable and Traversable typeclasses represent these use cases, are more general, and have none of the clunky edges mentioned in the article.

But Range is a concrete type, not an interface, right? And most of the discussion here is about the implementation of Range, not about the interface it exposes to users. Note also that the clone issue and the borrow issue are not applicable to Haskell, and that the performance characteristics of Range may be hard to replicate while implementing Foldable or Traversable.

Right, the trick is to not use concrete types when unnecessary. As the OP makes clear, it doesn't make sense to stuff all these use cases into a single concrete type.

> Note also that the clone issue and the borrow issue are not applicable to Haskell

No, but Rust switching to a typeclass-based iterator syntax should help with this too.

> the performance characteristics of Range may be hard to replicate while implementing Foldable or Traversable.

I don't see why - rustc generally does (and must do) a great job of specializing parametric code.

Re: My least favorite Rust type

#290

Post by tuesdayrain »

wokwokwok wrote: post #235
tuesdayrain wrote: post #223

Earlier quoted context omitted.

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.

Do you take joy in starting threads like this? You keep doing it. Just let it go. If you don't like the comment, down vote it. When you reply, you just create an irrelevant pointless subthread that has nothing to do with the actual post. Yes, this applies to the parent comment too... ...but the parent comment wasn't being a dick about it. Your comment is creating a pointless thread and being inflammatory, which is ju…

Basically all of your statements apply to your own post. You created a pointless subthread and resorted to direct insults that are far more inflammatory than anything I said.
Post reply on HN