New Issue: Exploring making 'range' a non-defaulted generic type?

Notifications Issues
1

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:

  • int indices
  • 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 : range to 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 domain and range w.r.t. being fully defaulted.