use of "->" operator (selector call expressions) for proc(s) with first parameter "this"

[renlite]

At the moment there are 3 steps necessary to use the syntax sugar of selector call expressions "->":

1. declaration in the struct for type proc
2. define the implementation of the proc outside the struct
3. set the proc as value of the declaration.

See example below:

Test :: struct {
	Name: string,
	// declaration hello
	_hello: proc(this: ^Test)   // 1)
}

//implementation hello
hello :: proc(this: ^Test) {    // 2)
	fmt.println(this.Name)
}

new_Test :: proc(name: string) -> Test {
	return Test{Name = name, _hello = hello}    // 3)
}

main :: proc() {

	foo_test := new_Test(name = "Foo")
	bar_test := Test{Name = "Bar"}
	hello(&foo_test)
	foo_test._hello(&foo_test)

	//*** -> operator (selector call expressions)
	foo_test->_hello()
	// No error - no output
	bar_test->_hello()
	
}

Solution 1):
Allow default values in the struct for all types. This would reduce Pt. 3) above.

Test :: struct {
	Name: string,
	// declaration hello
	_hello: proc(this: ^Test) = hello   // 1)
}

//implementation hello
hello :: proc(this: ^Test) {    // 2)
	fmt.println(this.Name)
}

main :: proc() {
	bar_test := Test{Name = "Bar"}
	
	//*** -> operator (selector call expressions)
	bar_test->_hello()
	
}

Solution 2):
Use the definition/implementation of the proc outside a struct as a member ot the sruct, if the first parameter in the proc is a pointer to a struct in the package . This would reduce Pt. 1 and Pt. 3.

Test :: struct {
	Name: string,
}

//implementation hello
hello :: proc(this: ^Test) {   // 2)
	fmt.println(this.Name)
}

main :: proc() {
	bar_test := Test{Name = "Bar"}
	
	//*** -> operator (selector call expressions)
	bar_test->hello()
	
}

I think Solution 2) would offer benefits without to break consistency and it is not an typical OO-design. You can still use the proc in common way. The first parameter name "this" could be mandatory if it fits design of Odin.

[flysand7]

You first described the way you might currently use selector call expressions, and then skipped directly to describing "solutions". Can you describe what the problem it is that you're trying to "solve"?

[laytan]

-> is designed for objective-c and windows COM interfaces, not for what you do here. We don't want methods.

[renlite]

With "selector call expressions" you have already methods. You mentioned two reasons and further could follow. (UI FW?)
Default values in structs would offer the same benefits as in procs.

[perrylets]

I think having x->y(foo, bar, etc) as an alias for y(x, foo, bar, etc) wouldn't break Odin's philosophy if it just called y with the first parameter being x no matter what x is (as long as y's first parameter accepts x's type). It's more characters but language servers could use it to filter available completions.