That’s a really nice explanation in the blog post.
I understand that no annotations are planned for the initial implementation of gradual types, however this did jump out as not ideal if annotations were supported:
$ a -> a when a: number()
def identity(arg) when is_number(arg), do: arg
Using both the guard and the annotation seems quite redundant, one of the reasons I don’t enjoy writing type specs and repeating myself.
Has there been any thought on how annotations and guards can replace one OR the other? (i.e. NOT both)
If for arguments sake we have the following annotation with no guard:
$ a -> a when a: number()
def identity(arg) do: arg
Could we expect the compiler to add the guard when is_number(arg) automatically?
Or turning this around taking annotations off the table completely where the complier respects guards and only the guards matter, would we still need another way to express return types?? Such as:
def identity(arg) returning number() when is_number(arg), do: arg
Or with different combinations of types:
def identity(arg)
returning integer() when is_number(arg) or
returning float() when is_float(arg) do: arg
def identity(arg)
returning number() when is_number(arg) or when is_float(arg) do: arg
def somefunc(arg)
returning ModuleA.t() when is_number(arg) or
returning ModuleB.t() when is_float(arg) do: ....
Ideally multiple return clauses might be a signal to the developer to actually define specialized functions.
Just saying I would rather the compiler support directly expressing the return type as part of a function guard if the compiler cannot infer the return type, than requiring repeat yourself annotations. Ideally I hope this is not required in the fullness of time and the compiler doesn’t need annotations or returning clauses at all not discounting the need for types on structs.
