Discussion: Adding Constrained Range Integer

[codecore]

Instead of code like this:

    public static ManagerWarning GetManagerWarningForUnit(int unitIndex)
    {
          if (unitIndex < 0 || unitIndex > 15)
          {
                throw new ArgumentOutOfRangeException();
          }
          return (ManagerWarning)(1 << unitIndex);
    }

We could have this:

      public static ManagerWarning GetManagerWarningForUnit(int[0:15] unitIndex)
      {
              return (ManagerWarning)(1 << unitIndex);
      }

Or how I like to write it:

     public static Func<int[0:15],ManagerWarning> GetManagerWarningForUnit = (unitIndex) => (ManagerWarning)(1 << unitIndex);

Also, add new keyword 'retrun' that acts just like 'return' :)

[Pzixel]

Duplicate of dotnet/roslyn#119

[codecore]

Not quite. This is a type, that has some compat with a full-range int. All the fun type checking can be applied to this at compile time, rather than the run-time exception that 119 proposes. I thought Module 2 had a range type, but I can't find it. So the constrained range (CR) int may be a subtype of an int. with overridden operators. Anything that can take an int, can take a CR int. To convert an int to a CR int requires a range check. See the null object mitigation work that MADS is talking about for inspiration on this conversion. CR ints are equivalent (the same type) if their range is the same.

[HaloFour]

I'd suggest writing an analyzer which can use annotations to denote range. Having it supported directly in the compiler at this time I don't think makes sense. It would make more sense included in the larger proposal of method contracts.

[Pzixel]

@codecore why then not add types odd integer, even negative integer, ..? It's just an overkill

All the fun type checking can be applied to this at compile time, rather than the run-time exception that 119 proposes.

Current code contracts allow static contract checking. I suppose that this proposal would be done in the same manner.

[bondsbw]

I think this may be more of a duplicate of #413.

[codecore]

This looks much like 413. @scottdorman makes a good case for it. I see applications for CR types where your standard numeric types are just too unbounded. I've struggled with Latitude and Longitude and CR would be an answer. https://github.com/codecore/Functional/blob/master/Functional/GPS/LocationContract.cs

[MgSam]

Method contracts seems to cover this. And being those are unlikely to happen anytime soon, why not just use a helper method?

public void Foo(int i) 
{
    Assert.Between(i, 0, 42);
    ...
}

[scottdorman]

Yes, this seems like it would be covered by #413.

@MgSam, I don't see how method contracts or your example of using an Assert actually cover this scenario. Yes, they may cause the runtime to fail if the value is outside of the allowed bounds, but have no influence on compile time checking and don't actually describe the intent. Having a constrained integer type clearly defines that the type should only ever have values within that range and makes that part of the actual type definition.

@HaloFour, an analyzer doesn't solve the problem here. I also don't see how method contracts would cover this either.

@codecore Yes, constrained types would solve the unbounded issues you have with the Latitude and Longitude pretty cleanly and clearly define the value ranges.

[MgSam]

This proposal doesn't say anything about compile time range checking. Seems like that would be of extremely limited utility. How often are you hard-coding values that you need a compiler to range check for you?

[scottdorman]

@MgSam No, this proposal doesn't, but #413 does and this is, by and large, a duplicate (or at least a subset) of what's proposed there. As for how often compile time checking would be useful, for me now, not so much any more, but when I was working in the defense industry it was needed/used all of the time to prevent damage to hardware. (See the example in #413, but think about software that controls a gimbal motor. The hardware can only travel a certain range before it suffers physical damage. Having constrained types prevents the software from allowing variables to approach those limits and also clearly defines the scope/range of the type.)

[MgSam]

I completely agree that a constrained integer type has uses, but it seems like it needs to be a runtime constraint. And it certainly doesn't need a special syntax.

[HaloFour]

@scottdorman

An analyzer is necessary to enforce the constraint at compile time rather than just letting it fail at run time, which is a stated goal of this proposal (at least per this comment). That would necessitate flow analysis that would be at least as complicated as that applied to non-nullable references, if not worse since these "constrained values" can continually narrow their ranges and the compiler would have to track every possibility that the value could be out of bounds.

Method contracts have the same problem. To be particularly useful they need static analysis during compile time to validate arguments. Without that and the metadata to facilitate that all of those proposals are frankly a waste of time. We don't need yet another syntax that will do nothing more than run time validation of arguments that bakes in some ideology as to how to react to invalid values.

I don't see how this proposal could be implemented effectively beyond an attribute of range metadata and flow analysis. The only other possibility would be that the compiler would have to spit out a struct for every possible range of each integral type. That's a Cartesian product of possibilities, each requiring a unique compiler-generated name that would be forced to follow a standardized convention as to not break public contracts, with zero possibility of unified types across assemblies. And that buys you nothing more than a forced explicit conversion and a failure at run time.

[iam3yal]

@codecore we discussed something similar back then that doesn't require new syntax using attributes, can check the discussion here but even this was controversial.

I really think that if you go this route you may need a very convincing use-case that isn't a niche for the design team to even consider something like this because currently, it looks like they don't seems to like the notion of contracts or well, they think that it's too verbose and maybe intrusive.

[bondsbw]

I think int[0..15] would be treated as a type. Casting an int into an int[0..15] would need to be explicit, but all constants between 0 and 15 would convert without casting.

This is no different from thinking of byte vs int vs long. Implicit casting to a superset type is allowed, to a subset type is not. Constants are evaluated by the compiler based on their inclusion in the set.

Really I think this is where type aliases make sense:

type UnitIndex = int[0..15];

public static ManagerWarning GetManagerWarningForUnit(UnitIndex unitIndex) {...}

...

GetManagerWarningForUnit(-1);  // Not allowed, -1 is not convertible to int[0..15]
GetManagerWarningForUnit(0);  // Allowed, 0 is convertible to int[0..15]

int i = 1;
GetManagerWarningForUnit(i);  // Not allowed, no implicit cast from int to int[0..15]

UnitIndex ui = 2;
GetManagerWarningForUnit(ui);  // Allowed

int[0..15] i0_15 = 3;
GetManagerWarningForUnit(i0_15);  // Allowed

int[4..5] i4_5 = 4;
GetManagerWarningForUnit(i4_5);  // Allowed, int[4..5] is a subset of int[0..15]

I'm not sure there is really a need for flow analysis.

[DavidArno]

Having used ranged integer types in Ada, back in the day, I can say with confidence that such types are way more trouble than they are worth. Sure it gives built in range checking, but it then leads to a plethora of incompatible int types throughout the code that have to be explicitly cast one from the other.

Also, with this proposal, the ranges are being expressed with "magic numbers", directly at the point of use, this would create a maintenance headache if those ranges had to change.

So a definite 👎 from me.

[jnm2]

@svick the type of max would be the union of the two ranges, int[0:3].
@DavidArno's magic number concern can be allayed by using aliases that give a semantic name to the range. Or just allow constants in the range spec.

[fanoI]

In some way an int[0:4 can be see as "parent" of a bitfield of 4 bit (a "nibble" if you like) in that contest the most correct name should be "bit4" as we proposed in this issue: #457.

As you can see these 2 problems can be solved using an analyzer that "magically" creates the struct types the problem is if for use of low level code you want to do the next pass and create a struct using them for example:

struct DoubleView
{
        Bit11 Fraction;
        Bit52 Fraction;
        Bit1 Sign;
}

the size of DoubleView should be 64 bit (same size of a double) to be useful but the compiler has yet no support for this.

[codecore]

@Pzixel You are treating my use as an integer with rules that constrain the range, where I am proposing a type that doesn't require any rules. The only gotcha is when you want to stick a regular integer into the constrained range integer. There are easy solutions for that. This is a type that acts just like a regular integer over a specific range. When things start getting out of that range at runtime, we have overflow, underflow, and argument range exceptions available. Also, the contract solution you propose requires verbose contracts on each function that takes it, while the CR integer type I propose has no such requirement.

[bondsbw]

@svick the type of max would be the union of the two ranges, int[0:3].

The existing signatures are

public static sbyte Max(sbyte val1, sbyte val2)
public static byte Max(byte val1, byte val2)
public static short Max(short val1, short val2)
public static ushort Max(ushort val1, ushort val2)
public static int Max(int val1, int val2)
public static uint Max(uint val1, uint val2)
public static long Max(long val1, long val2)
public static ulong Max(ulong val1, ulong val2)
public static float Max(float val1, float val2)
public static double Max(double val1, double val2)
public static Decimal Max(Decimal val1, Decimal val2)

I would expect it to use the byte flavor unless a new method is added.

[jnm2]

If the argument is typed as int, why would it use byte?

[bondsbw]

I presume byte since it is the smallest type that can hold both subsets. But I can see inferring int from the type definition.

[bondsbw]

Anyway, let's say that a new method were added to the API. What signature would it have? I think it would need to rely on Union/Or types from #399, as well as some new constraint syntax:

public static T|U Max(T val1, U val2) where T : long, U : long

[bondsbw]

(int might make sense here instead of long)

[bondsbw]

T : long means that T is a subset type of long.

[ghost]

I made the same proposal in #1198 but I think it is the generic form.

[ghost]

So, there are 4 possible ways to do it:

1. Method contracts. It is verbose but can write generic conditions.
2. Constrained Data Types: It is a compact syntax and can be extended to use regular expressions.
3. Validation attributes: Like those used in ASP.NET MVC. It has no effect on the c# syntax if self, and we can use parameters that indicate the error message or other actions. But using attribute for individual method parameters and return value can make the code long and ugly!
4. Writing an analyzer, which I cannot exactly understand !

Sure we all want some syntax to simplify validation codes.
We can make compromises. For example:
If the constrained types can cause problems, they can only be used to define properties and methods (parameters and return values). They are nit true types but just syntax annotations to tell compiler how validate values, so the compiler can convert then to contracts under the hood.
Attributes also can be used with properties and methods to supply error message and additional options to tell the compiler what to do when the data are not valid.
This approach says that contracts can still be used in more complicated situations (but I see that it is easer to use regular code statements)

[jrmoreno1]

@codecore :

Not quite. This is a type, that has some compat with a full-range int. All the fun type checking can be applied to this at compile time, rather than the run-time exception that 119 proposes. I thought Module 2 had a range type, but I can't find it

Assuming you mean Modula2, it's called a subrange type (also called that in Pascal):
https://www.modula2.org/reference/subrangetypes.php

[codecore]

And here it is.... a constrained range int.
https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/

[franchyd]

@codecore I'm not sure that array ranges is the same thing as this request.

[HaloFour]

@codecore

And here it is.... a constrained range int.

That refers to #185. It doesn't constraint the possible values of an int or any numeric type. It is instead a way to define a range that can be used to slice types like arrays or strings:

var helloWorld = "Hello World";
var range = 0..4;
var hello = helloWorld[range];
Debug.Assert(hello == "Hello");