151–160 of 298 posts
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'm only just learning Rust so I don't know much about Rust development, but what are the chances that any of the suggestions listed at the end make it into the language?
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.
Earlier quoted context omitted.
Well, it was never my intention to do something that you would consider vandalism.
I know that, which is why I didn't rate limit or ban your account. These things mostly happen unintentionally. The thing is, though, we have to judge them by their effects, not intentions, since it's the effects that have...effects. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... You're a good HN user and the only thing that's needed here is a bit more mindfulness. I like the 'arson' analogy for this…
Quoted post unavailable.
I don't think it's reasonable to make a comment like this without explaining why. He has designed a programming language, so it seems fair to assume he'd have an understanding of programming language design.
Hasn't everybody and their mums/dads by now?
And even so, is that language succesful - to the extend that it means his ideas are more relevant that Rust's designers?
It's just a concept implementation at the moment, not a real industry / production / community language.
For literals, clippy will catch this by default: error: this range is empty so it will yield no values --> src/main.rs:2:9 | 2 | let x = 5..0; | ^^^^ | = note: `#[deny(clippy::reversed_empty_ranges)]` on by default = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#reversed_empty_ranges help: consider using the following if you are attempting to iterate over this range in…
Earlier quoted context omitted.
I think that's what you would expect. Why do you think it is strange?
I don't know, I just find the concept of lexicographically ordering vectors something that isn't really useful. Can you think of examples where this might be something you would want?
(I can also think of situations where you'd pass around strings as vectors of characters, but I think that's a bit of a stretch.)
Earlier quoted context omitted.
Most of the methods are constrained to types that implement PartialOrd.
Yes, but why does Rust's Range type not require this?
You don't notice as much normally as most structs do not expose their internals and the constructors are often constrained.
Earlier quoted context omitted.
I know that, which is why I didn't rate limit or ban your account. These things mostly happen unintentionally. The thing is, though, we have to judge them by their effects, not intentions, since it's the effects that have...effects. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... You're a good HN user and the only thing that's needed here is a bit more mindfulness. I like the 'arson' analogy for this…
I understand. Forum moderation is a hard job. I certainly don't want to make it harder.
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…
One of the main usage of `Range` is to be an iterator.
The other is to causally slice data structures.
For both use-cases would the proposed changes lead to major usability regressions and braking. Because you can't compiler time enforce valid ranges as many are not created at compiler time (e.g. `a.start()..b.mid()`) and making range creation fallible would in practice be a massive usability nightmare. E.g. consider `for x in (start..end).unwrap().iter { .. }` instead of `for x in start..end { .. }`.
The current solution while imperfect was chosen to fit the most common use-cases of it best.
For some very performance sensitive use cases where you need slicing of ranges and the way the std range does thinks is to slow/bad you can have alternatives which are faster but have usability drawbacks. But that's the exceptional case not the normal case.
Many of the other examples shown also seem kinda strange. E.g. `get_unchecked` as well defined as "an out of bounds array index" is well defined (it's only defined for Range it's also an unstable experimental API...).
Range need clones => only in use-cases it was not primary designed for.
Range is unsure when its valid => No it knows it's always valid but not all valid ranges can be used in all places without having errors, indexing a slice with a range can panic anyway (out of bounds access) so moving the error handling there is fairly sane. Also you really can't have fallible Range creation.
Range hides a foot gune => any exclusive from-to range in any language has this problem, it's why in mathematics there are 4 types of ranges
A Recipe for Rearranging Range => he/she somehow assumes you can magically make sure that start <= end without error handling but without that oversight on his/here part this changes would make Range a usability nightmare.
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…
Yes, I think it was a rushed type which should be a lot more constrained on 1.0 to allow for modifications later, which is how stuff is usually done in Rust. It also probably should have implemented IntoIterator instead of Iterator directly. It may also be my least favorite Rust type, but I don't think it's really that bad, and I'm thankful for whoever designed it as I find it still much better than slice-specific indexing syntax.