11 Replies
We don't have language support to implement this constructor the right way (no trait with associated types), and no one feels compelled enought to implement the overloads for
range.I don't understand why they say that Mojo is a super set of Python. It feels like another completely different language outside of the Python ecosystem.
It’s a WIP superset. There’s a lot of foundation left to build before things like that get built.
I understand, it is a goal for the future.
Mojo is trying to recreate the everyday Python experience on a typed foundation, and there's much left to be built.
@Orwink If you are interested, maybe you could make a PR adding said overloads, since the stdlib is open source.
you should be able to write this pretty easily too, since you’d just need to iterate over the range and set the values
Easy but tedious, since
range maps to three _RangeSomthing structs.At least until: https://github.com/modularml/mojo/pull/2949
GitHub
[stdlib] Consolidate range structs and fix length calculation by bg...
Having three different range structs is unnecessary and makes it difficult to do something like write a function that accepts a range as an argument since range will currently return 3 different ty...
That is closed because having multiple structs allows for specialization and for open ended ranges to be passed in registers. The solution is to have a Range trait that allows you to use them as iterators like Rust does, except ideally delay the iteration as long as possible since it can be iterated at comptime and expanded for fixed-length ranges, allowing for unrolling.
I'd agree that in the current stage, it's better implemented as three structs. But I don't believe this problem is fundamental: I don't think you can argue that we should expect
reversed(range(n)) being slower as range(n) since the former uses the most general range structure. Also, a single iterator trait will cause the same specialisation problem if specialisation is indeed the problem, we may still need something like SizedIterable like in Swfit or c++.I agreed we need an ExactSizeIterator trait. Ideally I’d like on where it’s a contract violation to not be exactly that size, one where it’s a guess with no ability to rely on it, and another where its size is a range.
All of those are very useful once we get into heavy generics and you want to get properties out of your iterator for performance reasons.