Open dabrahams opened 1 year ago
Would you expect to be able to overload on accesses? There's currently no check making sure that you we can't define invalid overloads (or even duplicate functions), but I would personally expect the compiler to complain about the second definition of s
being illegal.
Overloading on access might not be possible because the type checker won't have a reliable way to pick a candidate until at least LUA is complete. Ideally, I'd like to avoid making the type checker dependent on the IR.
You know me, I loathe overloading :-). C++ people will expect this.
It comes up with pointer design because you might want pointer[to: x] -> Pointer<T>
and pointer[to: &y] -> PointerToMutable<U>
to work. I think the latter might end up being called pointer[toMutable: &y]
unless there's overloading.
Part of me wonders if it's even worth distinguishing the two types of pointers, but we can leave that for another discussion.
On the other hand, with effect parameters, we might have Pointer<T, let>
and Pointer<U, inout>
.