Numeric ranges

[PavelVozenilek]

If V will support numeric ranges (number can have values from 2 to 50), here's possible syntax which does not require new keywords, arcane concepts or use of cryptic prefixes/suffixes.

type my-restricted-int = int
[ // here are the restrictions, in form of asserts understood by the compiler
  assert(my-restricted-int >= 2) // this informs the compiler about the lower limit
  assert(my-restricted-int <= 50) // upper limit
]

It is possible to go further this way, and add runtime checks (used in debug mode):

type odd-number = int
[ 
  // runtime check, the compiler would respond by inserting this assert 
  // after each direct assignment in debug mode
  assert(is-odd-stdlib-func(odd-number)) 
]

Combination of compile time and runtime checks:

// odd number <= 100
type my-num = int
[ 
  assert(my-num <= 100)
  assert(is-odd-stdlib-func(my-num)) 
]

---

Similarly, pointer values could be restricted, without overdoing it with crazy combinations of prefixes.

Here are few possibilities:

type my-ptr = *int
[ // things that could be verified at the compile time

  // cannot be incremented/decremented
  assert(my-ptr.changeable = false) 

  // nullable pointer, if this gets supported
  assert(my-ptr.nulness == true) 

  // cannot point to a value on stack
  assert(my-ptr.points-to-stack == false) 

  // cannot point to heap allocated block or inside the heap allocated block
  assert(my-ptr.points-to-heap == false) 

  // has to point at the start of heap allocated block, but not inside
  assert(my-ptr.points-to-heap-head == true) 
]

The compiler could check that a desired property is preserved. E.g if I try to assign nullable pointer to non-nullable, there has to be a null check before. The compiler would refuse it otherwise.

---

Possibly, this form could be also used to restrict types in generics.

[ntrel]

There is a way to enforce that a field is never constructed with a value it should not hold using the optional return constructor pattern. The constructor function for a struct OddInt would be:

struct OddInt {
  i int
}
fn odd_int(i int) OddInt? {
  return if i & 1 {OddInt{i}} else {none}
}

This forces the programmer to handle none or visibly write opt? instead of silently asserting at runtime.

[PavelVozenilek]

Hmm, it feels quite complicated. The asserts are intended for against rare bugs. Once these bugs are chased out, what remains is simple code (plus those asserts, but one learns to skim over them). Constructs like above would remain even in perfectly debugged code, and decrease readability.

C++ allows lot of similar tricks, but IME they are not worth the trouble.

[ntrel]

If asserts can be stripped out, the test for optional? could be too.