Proposal: Fully Inclusive Ranges

[colejohnson66]

Background

C#'s ranges can only be [start, end) (inclusive start, exclusive end). This is a bit limiting.

For example, I have some code that can extract a Range of bits from a number:

public static class IBinaryIntegerExtensions
{
    public static T GetBits<T>(this T value, Range range)
        where T : IBinaryInteger<T>
    {
        // parameter validation removed for brevity
        int width = range.End.Value - range.Start.Value;
        T mask = (T.One << width) - T.One; // mask is right (bit zero) aligned

        return (value >> range.Start.Value) & mask;
    }
}

If I'm using said code to implement a bitfield and I wanted to get the field at bits 12 and 13 of the backing number, I actually have to pass a range of 12..14:

uint eflags = GetEFlags();
uint iopl = eflags.GetBits(12..14);

Any experienced C# programmer will understand that the above statement will only get 2 bits (14 - 12 == 2), but it requires extra thought that could be avoided.

On the other hand, Rust's ranges can be fully inclusive and would allow me to write:

let eflags: u32 = get_eflags();
let iopl = get_bits(eflags, 12..=13);

I propose C# support the same.

Proposal

This would be implemented as syntax sugar on top of the existing Range syntax:

int start = ...;
int end = ...;
// ...
Range range = start..=end;      // source
Range range = start..(end + 1); // desugar

ldloc.0      ; `start`
call valuetype [System.Runtime]System.Index [System.Runtime]System.Index::op_Implicit(int32)
ldloc.1      ; `end`
ldc.i4.1     ; <-- compiler would insert
add          ; <-- these opcodes
call valuetype [System.Runtime]System.Index [System.Runtime]System.Index::op_Implicit(int32)
call instance void [System.Runtime]System.Range::.ctor(valuetype [System.Runtime]System.Index, valuetype [System.Runtime]System.Index)

The compiler and JIT would perform constant folding as necessary.

Open-ended ranges (i.e. ..= and a..=) would be illegal with this new syntax, as a..= would have whatever nonsensical value Index.End + 1 would be.

The "from end" syntax would need discussion. There are three possible options for what ..=^a would mean:

• ..=^(a+1)
• ..=^(a-1) (from ..=(~a+1))
• illegal

The first would mean stc[..=^1] (desugared as src[..^2]) follows what some people's expectation of ranges is ("one from end means all but the last"), not what is currently is. The second would mean src[..=^1] (desugared as src[..^0]) causes an exception when slicing. The final option is to just make it illegal and avoid any confusion.

[The-Futurist]

There was a discussion a while back about considering additional notation for representing inclusivity/exclusivity but there was little interest in the idea.

[colejohnson66]

Both of those proposals are about range patterns for matching. My proposal is about actual Range objects.

[The-Futurist]

@koszeggy - FYI, this is the thread I was thinking of.

[colejohnson66]

@Korporal I don't see anyone arguing that a fully inclusive form is wrong; mostly just you arguing that the design is bad. I'd agree with the others that [a,b) (inclusive+exclusive) is more useful/desired than [a,b] (both inclusive). However, that doesn't preclude enhancing the feature now that ranges have been shown to be useful.

That thread even contains a comment by Cyrus with a paragraph that reads:

As i've also mentioned, nothing about hte [sic] current design precludes adding inclusive ranges in the future. however, that assessment will be done at a later point to see if it's really necessary or not. The belief is that exclusive is best to have first, and inclusive can be added later if appropriate.

Hence, my proposal. I agree that fully inclusive range forms aren't as common, and not useful in many scenarios (most array/list indexing). However, bitfields tend to be documented with inclusive ends (such as IOPL in my example being bits 12 through 13, not 12 to 14), and a fully inclusive form would match that.

[The-Futurist]

@colejohnson66

Talking of bits, I was quite taken by the mechanism discussed here by Niklaus Wirth in Pascal and Modula 2 and Oberon, referred to as "SET".

That idea perhaps coupled with range related concepts might have some potential in the case of bit fields.

See this too, be interesting to see if the syntax mixing ( and ) with [ and ] could be supported.

[colejohnson66]

@Korporal Allowing mixing of parenthesis and brackets to indicate inclusivity/exclusivity (as done in math notation) would be a neat idea, but I think that ship has sailed. If the current range syntax were to change to such a form, [a..b] would suddenly become fully inclusive and cause OOB exceptions everywhere; ranges would've had to be implemented as [a..b) from the start, but that would certainly have caused many headaches with how ranges neatly fit in with this indexing (this[Range range]). For example, obj(a..b) to get a fully exclusive form looks a lot like a function call.

[kyoyama-kazusa]

Tadpole operator?

0..~-10 // 0..9
0..-~10 // 0..11