In-Range Data Types (easier way than Method Contracts)

[ghost]

EDIT:
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)**

I suggest to improve current numeric types by adding a way to set a value range. I don't ask for numeric range array . I want a limited value range variable that can have a single value within the range. This is a sort of value validation, that can be applied to Properties and will affect binding them to data entry controls.
This can be done by adding two readonly properties to each data type: Min, Max. The compiler should check them before assigning any value to the object.
Max and Min Values can also be set via the constructor.
The can be done also by some attributes, but it will be easier to give it a syntax like this
[5,10]int i = 7;
or
<5,10>int i = 7;
The compiler must not allow i to have any value < 5 or >10.
It should validate values before any assignment and raise overflow exceptions.
One can omit one limit:

 [,100]byte b = 90;
[13,]int a = 15;

or

<,100>byte b = 90;
<13,>int a = 15;

This will make it easy to write auto-properties like this:
[18,30]int Age {get; set;};
Or
<18,30>int Age {get; set;};

In-Range Data Types give an easier way to achieve Method Contracts. It is very clear that this syntax

public <0,Count>int Insert(T item, <0,Count>int index)   {
    return InsertCore(item, index);
}

is easear than:

public int Insert(T item, int index)
    requires index >= 0 && index <= Count
    ensures return >= 0 && return < Count
{
    return InsertCore(item, index);
}

If you constrained the data type, then you've already constrained all other language elements built with it.

Note:
If you want to complicate things, I suggest to use regular expression syntax such as:
[reg exp]int x;
This can allow writting constrains on string data types as well.

Another possible implementation:

    struct Range<T > where T : struct, IComparable
    {
        T Min { get; set; }
        T Max { get; set; }

        public Range(T min, T max)
        {
            Min = min;
            Max = max;
            _value = min;
        }

        T _value;
        public T Value
        {
            get => _value;

            set
            {
                if (value.CompareTo(Max) == 1 || value.CompareTo(Min) == -1)
                    throw new ArgumentOutOfRangeException();

                _value = value;
            }
        }

        public static implicit operator T(Range<T> r)
        {
            return r.Value;
        }
    }

Usage:

var range = new Range<int>(18, 60);
range.value = 20;

which can have a short syntax:

<18, 60>int range;
range = 20;

The importance of this synatax appeares when declaring properties and method parameters and return values
For example:

<10, 90>int Foo(<1, 10>int x)
{
    // ........
    return result;
}

The compiler translates it to:

int Foo(int x)
{
  var x_range = new Range<int>(1, 10);
  x_range.Value = x;
  // ........
  var result_range = new Range<int>(10, 90);
  result_range.Value = result;
  return result;
}

[alrz]

#105

[Joe4evr]

And for actual ranges: dotnet/roslyn#23205

[ghost]

I don't ask for numeric range array . I want a limited value range variable. that can have a single value granteed to be in the range. This is a sort of value validation, that can be aplied to Properties and will affect binding them to data entry controls.

[yaakov-h]

#105?

[MkazemAkhgary]

I dont think its needed. You can already achieve it using struct and implicit operator.

struct Percent
{
    int value;
    public Percent(int value)
    {
        if(value > 100 || value < 0)
            throw new ArgumentOutOfRangeException(nameof(value), "percentage must be within 0-100");
        this.value = value;
    }
    
    public static implicit operator int(Percent value) => value.value;
    public static implicit operator Percent(int value) => new Percent(value);
}

[MkazemAkhgary]

In case default value should not be 0 use constant offset.

struct YoungAge 
{ 
    const int min = 18;
    const int max = 35;
    int age; 
    public YoungAge(int age) 
    { 
        if(age > max || age < min) 
          throw new ArgumentOutOfRangeException(nameof(age), $"young adult age is beween {min}-{max}"); 
        this.age = age - min;
    }
    public static implicit operator int(YoungAge age) => age.age + min; 
    public static implicit operator YoungAge(int age) => new YoungAge(age - min); 
}

[yaakov-h]

@MkazemAkhgary That gives you no compile-time safety, it only automates a handful of exceptions.

[Joe4evr]

I don't ask for numeric range array. I want a limited value range variable.

Yes, but that is constraining a value to be within a range. Completely different from the range itself.

[ghost]

@MkazemAkhgary
I think you miss the point. Almost every thing can be done with c# 3.0. The idea here is to save time and effort wasted in repeated tasks. We lived before Tuples but our lives will be easer after them.
C# is compiled to IL then IL is compiled to machine language. This 2-step compilation gives us the opportunity to complicate c# syntax as we want to save programmers time and effort, without affecting the JIT Compiler.
So, let's do that. Let's add syntax to shorten repeated poring tasks. Why not?
You wrote a page to accomplish what I suggested in one line!
Thanks.

[ghost]

@yaakov-h
Why you keep pasting the same link?
I looked there put couldn't find something similar to my idea, so I posted it there. Can you please explane what you mean?

[ghost]

@Joe4evr
I don't get it. If there a method to do what I suggested here in short easy way, please write a code sample.
Thanks.

[yaakov-h]

ah, I didn't see @alrz had posted it already.

@MohammadHamdyGhanem If you click through from that proposal to the original Roslyn issue, you should see how it's relevant.

[ghost]

@yaakov-h
Sorry, I cann't relly understand you. Could you care to explain. "see how it's relevant". What is "it"? Are we in the same page here?

[yaakov-h]

I fear you've fallen out of the book completely. 😄

You appear to asking for a way to constrain a variable or property to have maximum and minimum values.

This sounds like part of method contracts, which is a proposal based upon the old Microsoft Research project, Code Contracts.

The idea here is more general than your specific case, but would allow you do something like:

class RiskyDriver
{
    public int Age ensures return >= 18 && return < 25 { get; }
}

[ghost]

Yes. I read that and it is very clear that my syntax is easear:

public <0,Count>int Insert(T item, <0,Count>int index)   {
    return InsertCore(item, index);
}

than

public int Insert(T item, int index)
    requires index >= 0 && index <= Count
    ensures return >= 0 && return < Count
{
    return InsertCore(item, index);
}

If you constrained the data type, then you've already constrained all other language elements built with it.

[bondsbw]

@Pzixel No, you made the claim that 99% of arrays have sizes that cannot be determined until runtime. The burden is yours to prove your claim. Regardless, you are focusing on a single case of several I described.

Who said this was for locals only? You are the first to mention it.

[Pzixel]

@bondsbw

No, you made the claim that 99% of arrays have sizes that cannot be determined until runtime. The burden is yours to prove your claim. Regardless, you are focusing on a single case of several I described.

Ok, I will after you prove yours :)

Who said this was for locals only? You are the first to mention it.

You don't know array length when you passed it into the method

public void Foo(params int[] args) => // do we now length of args at compile time here?

[bondsbw]

That isn't how burden of proof works. You made the claim. I made the counterclaim. You must prove the claim before expecting me to prove the counterclaim.

You do know the array length when it is a constant. Obviously if it isn't a constant, then this feature doesn't apply.

[theunrepentantgeek]

There's another reason why Range data types are a bad idea - and it's something that I haven't seen mentioned yet in this thread. Consider this class and imagine you have a non-trivial system (>250kloc) that makes extensive use of it:

public class AdultWhoCanDrink
{
    public string FullName { get; }
    public string KnownAs { get; }
    public string OrderKey { get; }
    public <18,99>int Age { get; }
}

What happens when the local government changes the law and now the legal age for drinking alcohol is going to change to 21 years of age?

Worse, the type declaration <18,99> int is dispersed throughout your codebase - and the new legislation becomes effective in 28 days.

If you think this is a contrived example, I challenge you to check out some of the so-called constants in your local jurisdiction. Things like age thresholds (e.g. for voting, drinking age, or for military service), sales tax rates (e.g. NZ GST), and food standards (e.g. how much meat is needed a sausage) are inevitably political decisions - and those can change, sometimes with very short notice.

Simply using int throughout the code isn't a great solution, suffering as it does from primitive obsession.

Instead, we can define DrinkingAge with the appropriate rules and use that throughout the code. Then, when changes are required, we only need to make the change in one place.

We can already define DrinkingAge as a struct, incurring a very low memory cost (lower than a generic range type, in fact).

If the language did support range types, we'd only need to use them in one place … so the benefit to the codebase would be very low.

A last couple of comments …

… with Method Contracts, we could appropriately annotate the DrinkingAge type and get enforcement throughout the codebase without needing to repeat the rules over and over.

… if memory serves (it's been a long while since comparing programming languages in my university days), the experience of Ada developers using ranged type reflects this problem as well. They have nice characteristics when first writing code, but at the cost of making future feature development significantly harder.

[bondsbw]

@theunrepentantgeek

What happens when the local government changes the law and now the legal age for drinking alcohol is going to change to 21 years of age?

If such changes occur regularly, or if you need to deal with multiple jurisdictions that have different definitions, then keep it as an int or use a type which checks against a variable range, say from a database or configuration file. Those solutions fit your problem better.

Nobody is getting rid of int.

If you think this is a contrived example, I challenge you to check out some of the so-called constants in your local jurisdiction.

This is a design decision. In a previous job we made the decision to hard-code the list of US states into an enum within an offline app, instead of creating a web service for periodically syncing the list.

Could the states change? Sure, there has been talk about adding Puerto Rico for a while now. Did we feel it was worth the cost instead of simply releasing an update to the app? No, since the lead time for this change would be longer than our typical update schedule.

[bondsbw]

Worse, the type declaration <18,99> int is dispersed throughout your codebase - and the new legislation becomes effective in 28 days.

As I mentioned before, type aliases can be handy here:

type DrinkingAge = int<18,99>;

Now just change that once and push out an update.

sorry, I really don't like putting the brackets and numbers first

[ghost]

Another possible implementation:

    struct Range<T > where T : struct, IComparable
    {
        T Min { get; set; }
        T Max { get; set; }

        public Range(T min, T max)
        {
            Min = min;
            Max = max;
            _value = min;
        }

        T _value;
        public T Value
        {
            get => _value;

            set
            {
                if (value.CompareTo(Max) == 1 || value.CompareTo(Min) == -1)
                    throw new ArgumentOutOfRangeException();

                _value = value;
            }
        }

        public static implicit operator T(Range<T> r)
        {
            return r.Value;
        }
    }

Usage:

var range = new Range<int>(18, 60);
range.value = 20;

which can have a short syntax:

<18, 60>int range;
range = 20;

The importance of this synatax appeares when declaring properties and method parameters and return values.

[Pzixel]

Anyway it has type Range<int> rather than <18,60> int. It means that this value may be passed everywhere Range<int> can be accepted. You probably want compiler to generate checks on min and max values in all methods, but this is no-no imho.

[ghost]

You probably want compiler to generate checks on min and max values in all methods, but this is no-no imho

Why? checks exists already in the Value property. Whenever T is passed to a range, the compiler sets Range.Value = T and it will accept the value or throw an exception.
On the oher hand, Rang can be safly converted to T becuase it is a widening cast. I see this is an easy solution.

[Pzixel]

@MohammadHamdyGhanem

void Foo(<20, 40>int range) => Console.WriteLine(range);
<18, 60>int range = 59;
Foo(range);

Compiles to:

void Foo(new Range<int> range) => Console.WriteLine(range.Value);
var range = new Range<int>(18, 60) { Value = 59 };
Foo(range);

And fails at runtime. Where is the profit from having this type?

The problem here is that we are not in C++ world and we cannot write Range<int, 20, 40>. Range tresholds are not encoded in the type.

[ghost]

Where is the profit from having this type?

Look at this:

<10, 90>int Foo(<1, 10>int x)
{
    // ........
    return result;
}

The compiler translates it to:

int Foo(int x)
{
  var x_range = new Range<int>(1, 10);
  x_range.Value = x;
  // ........
  var result_range = new Range<int>(10, 90);
  result_range.Value = result;
  return result;
}

The the profit:
1- A compact time-saving code.
2- You easily realize what are method cntracts when you see this in a tooltip:
<10, 90>int Foo(<1, 10>int x)

And fails at runtime

You miss the point of code validation. Most methods and properties throw exceptions even those of the coreFX. We do this not to make the code fail at rune-time, put to foce our logic on any programmer that uses our code, so he had to provide valid values, and if he is not sure, he uses the try catch structure. This is how you design a reusable code for yourself and your team. In all cases the Foo method will reais an exception if it gets invalid values. The deference is that we don't have to write long validating code over and over.

[Pzixel]

You miss the point of code validation. Most methods and properties throw exceptions even those of the coreFX.

If I don't have compile time check I don't want to have it in the language. Ranges are rare enough. I'd rather prefer correct datetime interop (see NodaTime) than this one. Just write your own Range type then, you don't need language support for it.

Look at this:

It's beside the point. I show you that this feature gives nothing to me. It doesn't help to pass invalid range somewhere. It just save me some typing when I can write new <1,10>int(5) instead of new Range<int>(1,10) { Value = 5 }.

[ghost]

You can't use "new Range(1,10) { Value = 5 }" as a parameter type, or as a retrun value type, or as a property type. This is what the example shows.

[ghost]

It doesn't help to pass invalid range somewhere

Sure it does. I expect that the compiler will give you a design time error at:

<18, 60>int range;
range = 10;

and will give you a runtime error when a wrong value can't be calculated at design time. This is the standerd behavior with basic numeric types:

byte b = -1; // design time error
b = Foo( ) // if foo returns 300, runtime error

[HaloFour]

Frankly, the proposed <min,max>int syntax is pretty hideous and doesn't at all convey that it's related to contracts. The suggestion that it compile down to some generic Range type doesn't demonstrate how that can be helpful at compile time to avoid violation and runtime errors. That's on top of the fact that Range is going to mean something different in C# fairly soon.

If the language were to go down the path of exploring constrained types I'd much rather they be defined as proper type aliases with constraints, something akin to:

public type CustomerName : string;
public type CustomerId : Guid;
public type AgeRange : int where (AgeRange > 0 && AgeRange < 150);

The implementation could be a simple struct wrapper around the "extended" type:

public struct CustomerName {
    private readonly string value;

    private CustomerName(string value) => this.value = value;
    public static implicit operator string(CustomerName rhs) => rhs.value; 
    public static explicit operator CustomerName(string rhs) => new CustomerName(rhs);
}

Then you'd be able to use the type alias like a normal type and the compiler would require explicit casting to that type which would/should at least cause the developer enough pause to think about whether the type is valid.

When constraints are included those constraints could be embedded in the constructor to throw if violated at runtime. They could also be encoded into attributes which would allow for compile time validation, although that could be tricky if the syntax for defining constraints is fairly open-ended.