Proposal: Property naming in C++

[geoffromer]

This proposed style change allows C++ classes in the Carbon project to provide methods that are named like variables, so long as they behave like properties of the class. It also requires data member names to have a trailing _.

[chandlerc]

Nice! I like the wording in the style change.

I think if anything, the proposal has more motivation and detail than it needs, but that's not really a bad thing. =D I've illustrated a slightly different way of arriving at the same conclusion below mostly because it seemed interestingly different. If it happens to give a way to shorten and focus the motivation more, great, but really don't spend time worrying about it as I think what you have is also good. =]

Will at least let a couple of other eyes see this before fully stamping it, but I'm generally quite happy.

[jonmeow]

It might be worth noting somewhere, this'll also mean clang-tidy can't really re-case function names. Which perhaps should be included in this PR (a .clang-tidy update).

[chandlerc]

LGTM, but check with Jon about the outstanding comments. I think the new wording works, but good to confirm.

[jonmeow]

I've been thinking about this, and maybe the omission of setter methods means I disagree with this proposal. It's not that I disagree with the accessor naming, it's that I disagree with the argument against mutators.

I can talk about this at length, but I view getters and setters as inseparable. There are plenty of examples in C++: in our underlying style guide, C++ tutorials, and elsewhere. To the extent that this proposal concludes my_var() + SetMyVar(x), I view this proposal as leaving code in an uncanny valley.

I can't see Carbon implementing getters without setters (I think there's no cross-language precedent for having one without the other), and I think there enough examples in other languages that I think MyObj.my_prop = x; syntax should be expected. Given that precedent, I think having getters without setters in our C++ style is a similar inconsistency that shouldn't be adopted.

[geoffromer]

It might be worth noting somewhere, this'll also mean clang-tidy can't really re-case function names. Which perhaps should be included in this PR (a .clang-tidy update).

Done.

[chandlerc]

I think the next step here is just to update for mutating?

[chandlerc]

I'm generally happy here, a minor suggestion below. I'd like to check with @zygoloid before you land it though.

[jonmeow]

I'm generally happy here, a minor suggestion below. I'd like to check with @zygoloid before you land it though.

@chandlerc @zygoloid Any updates here?

[chandlerc]

I'm generally happy here, a minor suggestion below. I'd like to check with @zygoloid before you land it though.

@chandlerc @zygoloid Any updates here?

Chatted, and I think we're all fine.