Lint on method/struct fields sharing the same name

[gnzlbg]

Would it be possible to lint on the situation in which a struct field shares a name with a struct method? For example, in the following situation:

struct Foo {
  bar: i32 
}

impl Foo {
  fn bar(self);
}

[oli-obk]

This lint could have 2 versions. One that lints when the field is public (warn by default) and there's a method that could cause a collisions, and one that lints even if the field is not public (allow by default, since users of your type won't see it).

[TedDriggs]

Isn't this the preferred way of exposing public accessors for private fields?

[gnzlbg]

I thought that the preferred way of exposing public accessors for private fields was just to make the fields public. In particular, if you want to expose read/write access to the private fields, you need two accessors anyways right? So they cannot both have the same name.

[oli-obk]

Isn't this the preferred way of exposing public accessors for private fields?

That's why I suggested two lints. If both the method and the type are public, you get a collision, otherwise not.

[ssokolow]

@gnzlbg The way I interpreted @TedDriggs was something similar to Qt's approach:

• Property name: inputMask
• Getter name: inputMask()
• Setter name: setInputMask()

That said, as someone who programs mostly in Python, my solution there would just be to make the internal field name _inputMask.

UPDATE: ...though prefixing the property with an underscore would probably make it more difficult to auto-generate a nice table of properties in the style of Qt's docs.

[gnzlbg]

@ssokolow yeah I think i got it now, @oli-obk proposal should allow that.