The ownership of a nested field used inside a mutable method is incorrect

[yorickpeterse]

Please describe the bug

For expressions such as @some_field.nested_field, where nested_field is typed as T, if the surrounding method is fn mut, the return type is T instead of mut T. However, if the surrounding method is just fn the return type is (as expected) ref T. Thus, it seems that for fn mut we're no longer applying the correct ownership to nested fields.

Please list the exact steps necessary to reproduce the bug

Run this:

class Lexer[T] {
  let @input: T
}

class Parser[T] {
  let @lexer: Lexer[T]

  fn mut example {
    @lexer.input.TEST
  }
}

class async Main {
  fn async main {}
}

This produces:

/var/home/yorickpeterse/homes/arch/Downloads/test.inko:9:5 error(invalid-symbol): the method 'TEST' isn't defined for type 'T'

What it instead should produce is:

/var/home/yorickpeterse/homes/arch/Downloads/test.inko:9:5 error(invalid-symbol): the method 'TEST' isn't defined for type 'mut T'

Operating system

Arch Linux

Inko version

0.13.1

Rust version

1.73.0

Related issues

• Type inference error when matching against Map.opt_mut in certain cases #636
• Moving methods called on owned type parameters is problematic #618

[yorickpeterse]

The underlying problem is this:

In the above example, T isn't defined as T: mut, so when we end up calling TypeRef::as_mut() (when type-checking field access), we run into this code:

inko/types/src/lib.rs

Lines 3622 to 3626 in b3f73c5

	if pid.is_mutable(db) {
	TypeRef::Mut(id)
	} else {
	self
	}

Because of the lack of T: mut, we then return the type as-is.

This poses a new question: inside an fn mut, what should the type of a type parameter T be if it doesn't specify the mut requirement? If we return mut T we may allow mutations, which may be unsound (e.g. if T is a ref Something at runtime). If we return a ref T instead this could potentially be confusing, but at least it would be sound.

This is also related to #618, and specifically my thoughts in #618 (comment).