Bounding allowable type values could leverage immutable reference type checks

[davidroeca]

Likely out of scope, but worth considering as a simplifying assumption. Languages in the haskell family have immutable references built into their type systems, and this could enforce safer code. For example, fail the typecheck if reassignment of an immutable variable occurs, or classify the reference as mutable implicitly unless explicitly immutable.

var1 = 1  # type: Immutable[int]
var1 += 1  # typecheck fails; reassigned
var1 = 13  # typecheck fails; reassigned
def f1(x: int) -> int:
    return x
var1 = f1(12)  # typecheck fails; reassigned

Optionally, this could also extend to functionality involving allowed ranges--a number with typed bounds within an explicit range (e.g. IntegerGreaterThanZero), for example, must never be reassigned. The typechecker will have some amount of trouble in edge cases involving class attributes on reassignment. If the programmer wants the typechecker to respect a bounded number constraint, the typechecker could require that the reference is immutable. Type/function signatures/literals would suffice in a type check since assignment is only allowed once. Relates to #3062

EDIT 2:
Literals of int, str, etc. can be assumed as immutable function arguments by default since they're immutable objects, so the typechecker could implicitly be able to know that pow(1, 2) is an int (possible but definitely challenging) - immutable should merely subset.

EDIT:
Found some similar/duplicates, but I guess the main addition here is the link to bounded ints, etc.
#2795
#1214

[ilevkivskyi]

This is mostly a duplicate of #1214

IIUC what you also want to note is that constant types can be useful in conjunction with dependent types, namely we could not only support types that depend on literals but also on constants. Maybe you can add a comment in #1214 or/and in #3062? I am not sure we need to keep this issue open.

[davidroeca]

Yep, makes sense. Will add a comment