18215, "bradcray", "Exploring making 'range' a non-defaulted generic type?", "2021-08-12T23:13:33Z"
Traditionally, range has been a generic type that is fully defaulted, with:
- fully bounded
- not capable of storing non-unit strides
The argument being that this was the common case and the one we wanted to optimize most for.
However, this has also resulted in a few stumbling blocks:
- users are often confused that
var r: range = 1..n by 2;doesn't work and get frustrated at having to change it to
var r = 1..n by 2;or
var r: range(stridable=false) = 1..n by 2;
- arguments of range type need to be declared as
: range(?)rather than
: rangeto take "any range type", making them asymmetrical with
domain(which does mean "any domain type" because domains aren't fully defaulted)
While reviewing the range type today, @e-kayrakli proposed that perhaps ranges shouldn't have default values. My immediate reaction was "That's ridiculous!" but on reflection, I'm having trouble coming up with arguments for how the defaults are helping us. Just because they're the common case doesn't mean that we rely on the defaults in that way at all (e.g.,
1..n gets us that same common case without causing pain for anyone else).
To that end, this issue proposes we look into making
range partially or completely non-defaulted in its generic fields to see what the impacts are.
This relates somewhat to #18214 due to the asymmetry between
range w.r.t. being fully defaulted.