Member access expressions #989
Conversation
Co-authored-by: josh11b <[email protected]>
some additional examples.
Co-authored-by: josh11b <[email protected]>
Co-authored-by: josh11b <[email protected]>
There was a problem hiding this comment.
Largely LGTM. Some minor comments inline that just are about improving things, not really any changes.
Only thing seems like it'll have wider effect is being intentional around the naming of constructs here, especially "name" vs. "word". Feel free to submit if you see a clear resolution to everything here. But also fele free to poke for a fresh look if anything ends up changing enough to warrant it.
| Member access expressions associate left-to-right. If the member name is more | ||
| complex than a single _word_, an indirect member access expression can be used, | ||
| with parentheses around the member name: |
There was a problem hiding this comment.
Maybe:
| Member access expressions associate left-to-right. If the member name is more | |
| complex than a single _word_, an indirect member access expression can be used, | |
| with parentheses around the member name: | |
| Member access expressions associate left-to-right. If the member name is more | |
| complex than a single _word_, a member access _expression_ can be used, | |
| with parentheses around the member name: |
The word "indirect" for me adds more confusion than help, but the fact that it becomes an expression helps me. WDYT?
There was a problem hiding this comment.
Hmm, I see you really use these terms more heavily in the detailed design. I'll follow up there. This may not make sense to deal with until that is sorted.
| or an _indirect_ member access of the form: | ||
|
|
||
| - _member-access-expression_ ::= _expression_ `.` `(` _expression_ `)` |
There was a problem hiding this comment.
The term "indirect" here, and the distinction between "direct" and "indirect" doesn't really feel intuitive to me and for me gets confused with other uses of these terms. Any other ideas, maybe ones that more naturally reference the use of parentheses?
My ideas are to talk about "simple" vs "compound". I also might make it clear that this is about the specific member, so something like:
- member-access-expression ::= _expression
.member-name-expression
And then member name expresisons come in two forms. A simple and compound ones requiring paretheses:
- member-name-expression ::= (word | member-access-expression
))
But wide open to other ideas here, and if nothing else works this is fine. Just not my favorite. =]
github-actions
bot
added
the
proposal rfc
There was a problem hiding this comment.
LGTM, ship it.
We can tweak the nomenclature trivially afterward in this case -- I don't think it's reflective of a substantive misunderstanding in the design or intent in any way here, its just about finding the most clear way to describe it so that should be fine for a code review to fix forward. (If any real controversy comes up, can always make a leads question, but I don't think this is that big of a deal even with the current nomenclature.)
Ship it!
github-actions
bot
added
proposal accepted
Update precedence graph for new functionality.
Implement initial support for `A.(B)` syntax, per #989. Specifically, this supports: * `object.(Type.member)` for instance members, * `object.(Interface.member)` for instance and non-instance members, * `object.(Type.(Interface.member))` for instance members, * `Type.(Interface.member)` for non-instance members. Three new AST nodes are introduced: * `CompoundFieldAccessExpression` represents the `A.(B)` syntax. * `MemberName` is a `Value` that represents the result of evaluating an expression such as `Type.member` or `Interface.member` or `Type.(Interface.member)`. * `TypeOfMemberName` is the type of a `MemberName` value. In order to handle members of classes and interfaces which have corresponding declarations and may need substitution into their types, and members of structs which don't have declarations but also don't need substitution, a class `Member` is introduced that can refer to either of these kinds of member. Co-authored-by: Geoff Romer <[email protected]> Co-authored-by: Jon Meow <[email protected]>
Support for member access expressions with syntax `container.member`, covering cases such as: * `object.field` * `object.method(args)` * `package.namespace.class.member` * `object.(interface.member)` * `object.(class.member)` ... and so on. Includes the rule for template name lookup as decided in #949. Co-authored-by: josh11b <[email protected]>
Implement initial support for `A.(B)` syntax, per #989. Specifically, this supports: * `object.(Type.member)` for instance members, * `object.(Interface.member)` for instance and non-instance members, * `object.(Type.(Interface.member))` for instance members, * `Type.(Interface.member)` for non-instance members. Three new AST nodes are introduced: * `CompoundFieldAccessExpression` represents the `A.(B)` syntax. * `MemberName` is a `Value` that represents the result of evaluating an expression such as `Type.member` or `Interface.member` or `Type.(Interface.member)`. * `TypeOfMemberName` is the type of a `MemberName` value. In order to handle members of classes and interfaces which have corresponding declarations and may need substitution into their types, and members of structs which don't have declarations but also don't need substitution, a class `Member` is introduced that can refer to either of these kinds of member. Co-authored-by: Geoff Romer <[email protected]> Co-authored-by: Jon Meow <[email protected]>
First step in updating `docs/design/generics/details.md`. It incorporates changes from proposals: #989 #2138 #2173 #2200 #2360 #2964 #3162 , but there are still more changes from those proposals to be made. It also switches away from suggesting static-dispatch witness tables, and creates an appendix to describe that decision. --------- Co-authored-by: Richard Smith <[email protected]>
Continued from part 1: #3231. Second step updating `docs/design/generics/details.md`. There remains some work to incorporate proposal #2200. - The biggest changes are incorporating much of the text of proposals: - #2173 - #2687 - It incorporates changes from proposals: - #989 - #1178 - #2138 - #2200 - #2360 - #2964 - #3162 - It also updates the text to reflect the latest thinking from leads issues: - #996 - #2153 -- most notably deleting the section on `TypeId`. - Update to rule for prioritization blocks with mixed type structures from [discussion on 2023-07-18](https://docs.google.com/document/d/1gnJBTfY81fZYvI_QXjwKk1uQHYBNHGqRLI2BS_cYYNQ/edit?resourcekey=0-ql1Q1WvTcDvhycf8LbA9DQ#heading=h.7jxges9ojgy3) - Adds reference links to proposals, issues, and discussions relevant to the text. - Also tries to use more precise language when talking about implementations, to avoid confusing `impl` declaration and definitions with the `impls` operator used in `where` clauses, an issue brought up in - #2495 - #2483 --------- Co-authored-by: Richard Smith <[email protected]>
Support for member access expressions with syntax
container.member, covering cases such as:object.fieldobject.method(args)package.namespace.class.memberobject.(interface.member)object.(class.member)... and so on. Includes the rule for template name lookup as decided in #949.