mut parameter and interfaces

[tmssngr]

I have declared an interface and an implementation

interface SerialDataReceiver {
	fn write(data: Slice<byte>) -> Option<error>
}
...
impl DecodingSerialDataReceiver {
	fn write(self: Ref<DecodingSerialDataReceiver>, data: Slice<byte>) -> Option<error> {
		...
	}
}

That works just fine, but I want the reassign the data parameter. IMHO, this only should have influence on this function scope, but with mut

impl DecodingSerialDataReceiver {
	fn write(self: Ref<DecodingSerialDataReceiver>, mut data: Slice<byte>) -> Option<error> {
		...
	}
}

I'm getting the error

 ✕ Interface not implemented
     ╭─[src/main.lis:154:3]
 153 │     } else {
 154 │         DecodingSerialDataReceiver.new(file)
     ·         ──────────────────┬─────────────────
     ·                           ╰── DecodingSerialDataReceiver does not implement SerialDataReceiver
 155 │     }
     ╰────
  help: Incompatible methods:
          From SerialDataReceiver
            - write: expected fn (Slice<byte>) -> Option<error>, found fn (mut Slice<byte>) -> Option<error>
        code: [infer.interface_not_implemented]

Why I'm getting this error? IMHO it only would make sense if defining a parameter as mut would have influence to the caller. Maybe I misunderstood the whole purpose of defining parameters as mut?

[ivov]

mut marks the param mutable, which covers both reassigning it and writing through it. These are inseparable, and for Slice<T> and Map<K, V> a change to the contents is visible to the caller, so callsites have to pass a mutable binding. That makes it part of the signature even when your body only reassigns, which is why the interface has to declare it.

[tmssngr]

Do I understand it correctly, that this only applies for Slice<T> or Map<K, V> - or does it also apply for other objects? IMHO this mut-on-parameter-topic seems not worth the effort, because it covers just a tiny part of the intended safety. As discussed in other threads, this safety is completely gone for reference arguments, for example.

IMHO, reassigning the parameter variable should either always be allowed or prevented (at the end it just is a local variable for the function, just its initial value is passed as parameter); preventing to modify the passed object should either be supported completely, or given up. Currently, the mut on parameters promises safety in the non-mut-case which is not offered for a serious part of the cases.

[ivov]

mut for params applies to types that can carry mutation in Go unannounced, typically slices and maps. This is another case where the docs expect knowledge of Go semantics, see here.

mut controls rebinding and writability, which means you have to pay for both even when you only need one of them. Recently I've been thinking about splitting them, e.g. mut to protect from reassignment vs. Mut<T> to protect from write-through.

On the broader point, Ref<T> is exempt from mutability marking as the type itself already announces the value is shared, and Go has no read-only pointer. I see value in being able to signal that a slice or map may be mutated in an externally observable way when passed as a value.