hylo-lang / hylo

The Hylo programming language
https://www.hylo-lang.org
Apache License 2.0
1.24k stars 59 forks source link

Overloading function on inout doesn't work #689

Open dabrahams opened 1 year ago

dabrahams commented 1 year ago
fun s(_ x: Int)-> Int {
  x
}

fun s(_ x: inout Int)-> Int {
  x
}

fun use<T>(_ x: T) {}

public fun main() {
  use(s(3))
}
Pointers.val:12.7-8: error: ambiguous use of 's'
  use(s(3))
      ^
Pointers.val:1.1-3:2: note: candidate here
fun s(_ x: Int)-> Int {
~~~~~~~~~~~~~~~~~~~~~~~~
Pointers.val:5.1-7:2: note: candidate here
fun s(_ x: inout Int)-> Int {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kyouko-taiga commented 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.

dabrahams commented 1 year ago

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.

dabrahams commented 1 year ago

On the other hand, with effect parameters, we might have Pointer<T, let> and Pointer<U, inout>.