add a compile error note for field name shadowing struct member function

[andrewrk]

const xxx = struct {
    bar: u8,
    pub fn bar(self: *const xxx) void {}
};

pub fn main() !void {
    var x: xxx = undefined;
    x.bar();
}

O:\zig0.1.1\b.zig:10:4: error: type 'u8' not a function
  x.bar();
   ^

[andrewrk]

I'm going to call this "working as designed". The function is not actually shadowed by the field. It can be referenced like this:

const xxx = struct {
    bar: u8,
    pub fn bar(self: *const xxx) void {}
};

test "non-member fn call" {
    var x: xxx = undefined;
    xxx.bar(&x);
}

However, the error message could be improved with a note that says "note: 'bar' is both a field and a top level declaration". That's a relatively low priority though.

If we had different syntax for field access and for method calls, this would not be an issue. I wonder how well-received it would be for method calls to be a->b().

[daurnimator]

What about when you take the address of a member?

const xxx = struct {
    bar: u8,
    pub fn bar(self: *const xxx) void {}
};

test "non-member fn call" {
    var x: xxx = undefined;
    var bar = &x.bar; // do I now have a function pointer? or a pointer to the member
    bar(x); // what about now?
}

[tgschultz]

Related: #1836

[hryx]

I wonder how well-received it would be for method calls to be a->b().

Keeping in mind, if b were a namespaced function and c were a function pointer field, they would require different call syntax:

a->b();
a.c();

But honestly, that might be a good thing if struct "methods" are fundamentally different from struct fields. Which seems to be the case, considering that field values can be changed but namespaced functions can't.

(Possibly affected by this topic: #1717)

[raulgrell]

I quite like the idea of a separate syntax for method calls since it isn't just "accessing a child of a container", it's also sending an implicit first parameter.

Lua makes this distinction too, where foo:bar() is equivalent to foo.bar(foo).

I'd personally prefer :: instead of ->, both for aesthetic reasons and I believe a new meaning for :: is more easily learned than a new meaning for -> in terms of C/C++.

[ghost]

I'd personally prefer :: instead of ->, both for aesthetic reasons and I believe a new meaning for :: is more easily learned than a new meaning for -> in terms of C/C++.

One possible option is adding a leading comma inside the parenthesis.

a.func(14.3); // normal namespace function
b.func(,14.3); // method. equiv to `TypeOf_b.func(b,14.3)`

// example
const res = a.mul(b.add(c)); // currently
const res = a.mul(,b.add(,c)); //  --  this idea
const res = a->mul(b->add(c)); // traditional

// if spinning further on this idea, but going beyond the concern of this issue: 
// intended to be more explicit and give the reader more information
_ = c.func(,14.3); // method that does _not_ modify `c`
_ = d.func(*,14.3); // method that modifies `d` in place
_ = e.func(&,14.3); // calling a struct member on instance `e`. Run-time dependent behavior.

The leading comma isn't pretty, but it's not very obtrusive (IMO) either. Especially with syntax highlighting.

[Pyrolistical]

@daurnimator

What about when you take the address of a member?

some_struct.someMethod() is sugar for SomeStruct.someMethod(some_struct).

It is not possible to get a closure like reference to someMethod. someMethod doesn't exist on some_struct as a field, but does exist on SomeStruct as a declaration.

Getting a comptime reference to the someMethod declaration is possible:

const someMethod = SomeStruct.someMethod; // or @field(SomeStruct, "someMethod");
@call(.auto, someMethod, .{some_struct});

[Pyrolistical]

If we had different syntax for field access and for method calls, this would not be an issue.

One of the reasons why zig so comfy is how light its syntax is. I love the fact the . operator is overloaded:

foo.some_field
foo_ptr.some_field
foo.someMethod()
foo_ptr.someMethod()
foo_ptr.someMethodThatNeedsFooPtr()
Foo.some_declaration
Foo.someMethod
foo_ptr.*
optional_foo.?

I'm so happy I never need to write foo_ptr.*.someMethod() and the fact that ::/-> doesn't exist. In fact, I would go further and replace &foo with foo.&.

I am willing to pay the cost of having to write xxx.bar(&x); as this can be avoided by simply not shadowing.