Design overview update part 5: Names #1347
Conversation
docs/design/README.md
Outdated
| there should be exactly one definition for the name, but there can be additional | ||
| forward declarations that introduce the name before it is defined. Forward |
There was a problem hiding this comment.
Should we say that there can be at most one forward declaration? Given the other constraints we've put on forward declarations, it doesn't seem like there's any utility in having more than one forward declaration. (The #875 proposal mentioned this but didn't actually make a decision on it.)
The one exception I can think of is impls, where a declaration inside a match_first is meaningful even if there's another declaration elsewhere, but I think we can meaningfully distinguish forward declarations from match_first declarations given that match_first declarations have additional semantics. (friend declarations might also behave like match_first, depending on what rules we want for them.)
Perhaps the rule could be that there can be at most one forward declaration, any number of declarations inside match_first blocks, and at most one defintiion.
There was a problem hiding this comment.
I'm fine either way. I agree there is not much value beyond the first, other than the match_first case. We did say that a friend declaration does not declare the name.
There was a problem hiding this comment.
I switched to say at most one here.
Co-authored-by: Richard Smith <[email protected]>
Co-authored-by: Chandler Carruth <[email protected]>
docs/design/README.md
Outdated
| this is as if there was a special "prelude" package that was imported | ||
| automatically into every `api` file that declared these names. |
There was a problem hiding this comment.
| this is as if there was a special "prelude" package that was imported | |
| automatically into every `api` file that declared these names. | |
| this is as if there was a special "prelude" package which defines | |
| these types that is imported automatically into every `api` file. |
There was a problem hiding this comment.
I'm going to go with Chandler's rewrite. We can fix forward if it is still lacking.
|
To be clear -- I'm in favor of landing with whichever works best for now. We can always follow-up to better word stuff. (This goes for several of the points, just want to be explicit here, and not just directly in chats...) |
Co-authored-by: Chandler Carruth <[email protected]>
This follows #1274 , #1325 , #1328 , #1336 , #1347 , and #1368 . This fills in details about how values work, value categories, parameter passing, unformed state, and so on. Co-authored-by: Geoff Romer <[email protected]> Co-authored-by: Richard Smith <[email protected]> Co-authored-by: Chandler Carruth <[email protected]>
chandlerc
added
the
documentation
This follows #1274 , #1325 , #1328 , and #1336 . It fills in the "Names" section.