Naming conventions #861

jonmeow · 2021-09-29T20:09:06Z

For idiomatic Carbon code:
- UpperCamelCase will be used when the identifier can be resolved to a
  specific value at compile-time.
- lower_snake_case will be used when the identifier's value won't be
  known until runtime, such as for variables.
For Carbon-provided features:
- Keywords and type literals will use lower_snake_case.
- Other code will use the guidelines for idiomatic Carbon code.

jonmeow · 2021-09-30T19:45:51Z

@zygoloid @chandlerc Note, I'm trying to interpret the current rationale for the naming decision. I think I've accurately captured your perspective now: I had definitely misunderstood some of the discussions, but a quick thread with Chandler hopefully cleared that up. Given I may be inserting the wrong words into your mouths, please let me know if I'm still wrong.

proposals/p0861.md

jonmeow

Addressing comments

proposals/p0861.md

chandlerc

Trying to get back to this, again sorry for the delay. Suggestions and comments inline, and thanks for working on pulling all the different discussions together into a proposal.

chandlerc · 2022-01-07T08:50:17Z

proposals/p0861.md

+    -   `UpperCamelCase` will be used when the identifier can be resolved to a
+        specific value at compile-time.


I'm curious, would "value or entity" wore better or worse here?

Suggested change

- `UpperCamelCase` will be used when the identifier can be resolved to a

specific value at compile-time.

- `UpperCamelCase` will be used when the identifier can be resolved to a

specific value or entity at compile-time.

Specifically thinking about namespaces. @zygoloid might have thoughts on the specific wording of this.

An alternative way to phrase this we could consider: "UpperCamelCase will be used when the identifier names a specific program entity, such as a function, a namespace, or a compile-time constant value." This tries to anchor more on the "proper noun" kind of rationale.

Using the second suggestion, since I assume you prefer it.

One phrasing that came up in discussion with @chandlerc: "if the named entity cannot have a dynamically varying value".

FWIW, I think I prefer the latest version ("... names a specific program entity, such as ....") slightly over "cannot have a dynamically varying value". Maybe they could be combined?

Tried rephrasing...

I'm happy with the phrasing that you ended up with. I feel like I could apply it to understand why function parameters get one result and template/generic parameters get another result, and why a local let a: i32 binding gets one result but a global let A: i32 binding gets a different result.

proposals/p0861.md

chandlerc · 2022-01-07T08:58:27Z

proposals/p0861.md

+Private member variables should use a `_` suffix in order to prevent name
+collisions. We discourage private properties.


Could we skip this suggestion, at least for now? I'm not sure it will be needed in Carbon, and I'd rather not get ahead of that design.

Moved to an open question; I would emphasize, after #720 #898 #970, I'd really like to avoid digging the same hole in early Carbon code.

I'd just like to avoid pre-adopting a workaround for an avoidable design problem... Thanks for moving this to an open question, would it be OK to remove it from the list above as well?

Okay, but I'm a bit confused by your request... All I see in the above list is properties with no mention of _, so I assume you mean to remove properties altogether -- gone.

proposals/p0861.md

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

jonmeow

Addressing comments

jonmeow · 2022-01-07T23:28:43Z

proposals/p0861.md

+    -   `UpperCamelCase` will be used when the identifier can be resolved to a
+        specific value at compile-time.


Using the second suggestion, since I assume you prefer it.

proposals/p0861.md

jonmeow · 2022-01-07T23:29:30Z

proposals/p0861.md

+Private member variables should use a `_` suffix in order to prevent name
+collisions. We discourage private properties.


Moved to an open question; I would emphasize, after #720 #898 #970, I'd really like to avoid digging the same hole in early Carbon code.

chandlerc

I think the only main thing left is making sure we've converged on the least confusing phrasing for the UpperCase stuff. Some minor things elsewhere....

proposals/p0861.md

chandlerc · 2022-01-21T09:48:15Z

proposals/p0861.md

+    -   `UpperCamelCase` will be used when the identifier can be resolved to a
+        specific value at compile-time.


FWIW, I think I prefer the latest version ("... names a specific program entity, such as ....") slightly over "cannot have a dynamically varying value". Maybe they could be combined?

chandlerc · 2022-01-21T09:50:13Z

proposals/p0861.md

+Private member variables should use a `_` suffix in order to prevent name
+collisions. We discourage private properties.


I'd just like to avoid pre-adopting a workaround for an avoidable design problem... Thanks for moving this to an open question, would it be OK to remove it from the list above as well?

proposals/p0861.md

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

…eow/carbon-lang into proposal-naming-conventions

jonmeow

Addressing comments

jonmeow · 2022-01-21T18:59:32Z

proposals/p0861.md

+Private member variables should use a `_` suffix in order to prevent name
+collisions. We discourage private properties.


Okay, but I'm a bit confused by your request... All I see in the above list is properties with no mention of _, so I assume you mean to remove properties altogether -- gone.

jonmeow · 2022-01-21T19:07:10Z

proposals/p0861.md

+    -   `UpperCamelCase` will be used when the identifier can be resolved to a
+        specific value at compile-time.


Tried rephrasing...

proposals/p0861.md

chandlerc

LGTM with a minor tweak to Base below!

proposals/p0861.md

Co-authored-by: Richard Smith <richard@metafoo.co.uk>

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.

- For idiomatic Carbon code: - `UpperCamelCase` will be used when the identifier can be resolved to a specific value at compile-time. - `lower_snake_case` will be used when the identifier's value won't be known until runtime, such as for variables. - For Carbon-provided features: - Keywords and type literals will use `lower_snake_case`. - Other code will use the guidelines for idiomatic Carbon code. Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: Richard Smith <richard@metafoo.co.uk> Co-authored-by: josh11b <josh11b@users.noreply.github.com>

A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.

Primitive types have been renamed in pull request carbon-language#861 and also the design document.

Primitive types have been renamed in pull request #861 and also the design document.

jonmeow added the proposal A proposal label Sep 29, 2021

jonmeow requested a review from a team September 29, 2021 20:09

google-cla bot added the cla: yes PR meets CLA requirements according to bot. label Sep 29, 2021

jonmeow added 5 commits September 29, 2021 20:09

Filling out template with PR 861

d22b55f

Checkpoint

02ce321

Checkpoint

e638405

Drafting

4b27545

Filling in lead thoughts

3bb78db

jonmeow marked this pull request as ready for review September 30, 2021 19:43

github-actions bot added the proposal rfc Proposal with request-for-comment sent out label Sep 30, 2021

josh11b reviewed Sep 30, 2021

View reviewed changes

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

Edits

2284723

jonmeow commented Oct 11, 2021

View reviewed changes

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

jonmeow added 2 commits October 13, 2021 16:28

Merge branch 'trunk' into proposal-naming-conventions

811d60a

Merge branch 'trunk' into proposal-naming-conventions

1561d44

chandlerc requested changes Jan 7, 2022

View reviewed changes

jonmeow and others added 4 commits January 7, 2022 23:07

Merge llvm-project

fd0387b

Merge branch 'trunk' into proposal-naming-conventions

bb71d00

Apply suggestions from code review

49c10ce

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

Addressing comments

8361ea1

jonmeow commented Jan 7, 2022

View reviewed changes

jonmeow requested a review from chandlerc January 10, 2022 20:14

chandlerc reviewed Jan 21, 2022

View reviewed changes

jonmeow and others added 4 commits January 21, 2022 10:50

Update proposals/p0861.md

4dd4e57

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

Addressing comments

a09b9e4

Addressing comments

717283f

Merge branch 'proposal-naming-conventions' of https://github.com/jonm…

54a3e20

…eow/carbon-lang into proposal-naming-conventions

jonmeow commented Jan 21, 2022

View reviewed changes

jonmeow requested review from chandlerc and zygoloid January 25, 2022 18:19

zygoloid reviewed Jan 27, 2022

View reviewed changes

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

Merge branch 'trunk' into proposal-naming-conventions

c6e6322

chandlerc approved these changes Jan 27, 2022

View reviewed changes

proposals/p0861.md Outdated Show resolved Hide resolved

josh11b reviewed Jan 27, 2022

View reviewed changes

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

proposals/p0861.md Outdated Show resolved Hide resolved

jonmeow and others added 4 commits January 27, 2022 11:19

Update proposals/p0861.md

984874e

Co-authored-by: Richard Smith <richard@metafoo.co.uk>

Update proposals/p0861.md

5fc5771

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

Update proposals/p0861.md

5de6c33

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

Update proposals/p0861.md

8713b22

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

jonmeow merged commit 93a5fcd into carbon-language:trunk Jan 27, 2022

jonmeow deleted the proposal-naming-conventions branch January 27, 2022 19:25

github-actions bot added proposal accepted Decision made, proposal accepted and removed proposal rfc Proposal with request-for-comment sent out labels Jan 27, 2022

jonmeow mentioned this pull request Jan 29, 2022

Merge naming conventions #861 into the design #1056

Merged

jonmeow added a commit that referenced this pull request Jan 29, 2022

Merge naming conventions #861 into the design (#1056)

887d72d

A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.

chandlerc pushed a commit that referenced this pull request Jun 28, 2022

Merge naming conventions #861 into the design (#1056)

979fe2c

A pretty straight copy of #861. Cutting down README.md example text since it seemed a little redundant with examples in the bullets.

jonmeow mentioned this pull request Jul 19, 2022

Naming conventions for Carbon-provided features #750

Closed

ooxi added a commit to ooxi/carbon-lang that referenced this pull request Jul 24, 2022

Fix spelling of primitive types

c0c0aa5

Primitive types have been renamed in pull request carbon-language#861 and also the design document.

ooxi mentioned this pull request Jul 24, 2022

Fix spelling of primitive types #1663

Merged

ooxi added a commit to ooxi/carbon-lang that referenced this pull request Jul 24, 2022

Fix spelling of primitive types

60c5906

Primitive types have been renamed in pull request carbon-language#861 and also the design document.

jonmeow pushed a commit that referenced this pull request Jul 24, 2022

Fix spelling of primitive types (#1663)

6224f50

Primitive types have been renamed in pull request #861 and also the design document.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Naming conventions #861

Naming conventions #861

jonmeow commented Sep 29, 2021 •

edited

Loading

jonmeow commented Sep 30, 2021

jonmeow left a comment

chandlerc left a comment

chandlerc Jan 7, 2022

chandlerc Jan 7, 2022

jonmeow Jan 7, 2022

zygoloid Jan 21, 2022

chandlerc Jan 21, 2022

jonmeow Jan 21, 2022

zygoloid Jan 27, 2022

chandlerc Jan 7, 2022

jonmeow Jan 7, 2022

chandlerc Jan 21, 2022

jonmeow Jan 21, 2022

jonmeow left a comment

jonmeow Jan 7, 2022

jonmeow Jan 7, 2022

chandlerc left a comment

chandlerc Jan 21, 2022

chandlerc Jan 21, 2022

jonmeow left a comment

jonmeow Jan 21, 2022

jonmeow Jan 21, 2022

chandlerc left a comment

		- `UpperCamelCase` will be used when the identifier can be resolved to a
		specific value at compile-time.

		Private member variables should use a `_` suffix in order to prevent name
		collisions. We discourage private properties.

Naming conventions #861

Naming conventions #861

Conversation

jonmeow commented Sep 29, 2021 • edited Loading

jonmeow commented Sep 30, 2021

jonmeow left a comment

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonmeow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonmeow left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

jonmeow commented Sep 29, 2021 •

edited

Loading