added range_redesign rfc

[chobeat]

RFC for the range redesign. All the details are in text/0000_range_redesign.md

[SeanTAllen]

Markdown formatting seems a little off based on the highlighting that GitHub is doing

[SeanTAllen]

Looking at your reference code, its more explicit about inclusive and exclusive but reverse is now implicit. The reverse API is non-obvious in that fashion to me. I think this should be addressed in the RFC.

[jemc]

Can you include the important points of the API design in the RFC, along with a few usage examples?

I know you linked a reference implementation, but it's good to have the API design in the RFC itself for posterity, since the reference implementation link may become invalid later. Also, seeing usage examples would make this easier to talk about.

[chobeat]

I've addressed all the points you raised and I think the document is ready for another round of review.

[SeanTAllen]

"majority of ranges are defined with bounds know at compile time" isn't my experience. if the majority of ranges were defined with bounds at runtime, would that change the "never raise errors" idea?

[chobeat]

yes, because the assumption is that ranges defined with hardcoded value don't need error handling. The range will be either always valid or always invalid. If this is not the most common scenario, raising an error would be more idiomatic than checking is_invalid. The idea is to renounce an idiomatic interface to save the user a lot of unnecessary error handling.

[jemc]

It was mentioned on today's sync call that this implementation adds some allocation overhead that will significantly slow down use of Range in, say, a for loop.

Having Inclusive and Exclusive be a class containing a number means that they will be allocated as objects. Having them behind the trait Bound means that we will use virtual calls and not reified, which precludes inlining of the function and stack-allocation of the class.

To fix the performance issue, Inclusive and Exclusive could each be a primitive with no state, and the number is kept in a separate field. Making it use a primitive and a number separately means no allocation for that data. Additionally, they should be type parameters instead of runtime parameters, and iftype used to check the type parameter, so that the inclusivity/exclusivity control flow paths can be known at compile-time instead of runtime.

From a usability standpoint, it is suggested that we make sure the defaults for those type parameters are matching the current behaviour of Range for compatibility purposes.

[sylvanc]

Another issue for me is that dynamically determining forward or backward would interfere with high performance code patterns. For example, writing a loop that was intentionally a forward loop but that might (dynamically) intentionally perform zero iterations (by setting the begin as higher than the end). This is common in, for example, matrix multiplication (a scenario of particular interest for me).

Much like @jemc says above for inclusive and exclusive, forward and backward could be encoded as primitive type parameters, allowing zero-cost reification.

[jemc]

Removing from final comment period until the above comments are addressed.