Clear distinction between storing a value and storing a pointer in an interface

[vtereshkov]

Umka could do it the same way as Go does. This would be more consistent than Umka's interfaces.

However, it would require two extra features:

• A means of indicating that a type assertion with a value type has failed. For example, Go's type assertion syntax in separate from type casts. @skejeton proposes a new cast-like assertion in the form ^T(&interfaceValue) that can return null on failure.

• Methods with non-pointer receivers. See the Go example: https://go.dev/play/p/tQx7GNmhzDm

[skejeton]

Why would it needs methods on non pointer receivers?

[vtereshkov]

@skejeton For consistency. For example, you can treat methods on non-pointer receivers as const methods in C++, i.e., the only methods applicable to a const object. When I put a non-pointer value into an interface, this value may be a const. What would a method acting on a pointer receiver mean here? That the constant should be addressable? That the method could modify it?

[skejeton]

@vtereshkov But the value type interface isn't immutable/const. On a normal value type you can call methods with pointer receivers, which implicitly takes reference of itself.

[vtereshkov]

@skejeton On a value-typed var you can, on a value-typed const you cannot.

[skejeton]

@vtereshkov Makes sense, but this is about const/var, not imterfaces. Isn't it?

[vtereshkov]

@skejeton Interface methods should act exactly as the corresponding concrete type methods. They shouldn't expect a pointer to a const, for example.

[skejeton]

@vtereshkov i don't get it, why are we talking about consts?

[skejeton]

I think I understand what you meant now. Now that we don't have structured constants, do we need value typed methods?