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"?

[gingerBill]

Exactly. What exactly is the problem?

[renlite]

Reduce the steps (less coding) to use sugar of selector call expressions "->". Solution 1) wourd reduce the step 3 if default proc is ok. Methods style call is available -> it could be easier to use. Less to init if default values of properties (not only procs) are possible.

[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.

[tymbaca]

IMO the "only functions" approach makes the thought process simpler. You just don't need to think "do I need to make it a method or a function?"

As an alternative, it can be a good feature for odin lsp (ols) to transform this bar_test.hello() to this hello(bar_test).

[laytan]

OLS actually has this, if you put "enable_fake_methods": true in your config it will complete check for available functions of which you can pass the thing as the first parameter.

Foo :: struct {}

foo_hello :: proc(a: Foo) {}
foo_bar :: proc(a: ^Foo) {}

main :: proc() {
    f: Foo
    f.
}

Upon typing that period it would complete both of those procs and transform into the proper foo_hello(f) when accepted.

[flysand7]

big