Update member access design doc to reflect proposal #3720: Member binding operators - #7557
Update member access design doc to reflect proposal #3720: Member binding operators#7557josh11b wants to merge 4 commits into
Conversation
github-actions
Bot
added
the
documentation
chandlerc
left a comment
chandlerc
left a comment
There was a problem hiding this comment.
Generally this LGTM, but I think Richard should also take a look to make sure I'm not missing anything...
| - The type of an interface method taking `ref self` would also implement `BindToRef(T)`. | ||
| - In all cases, the type of an interface member would implement `BindToType(T)` for all types `T impls I`. The result would depend on the specifics of the member, but generally would be a value of a unique empty type associated with the specific interface member, parameterized by `T`. This value could then be bound to an instance of `T` in a succeeding operation. | ||
|
|
||
| ### Member binding restrictions | ||
|
|
||
| The restrictions that only certain compound member accesses are valid are naturally enforced by whether the | ||
| member's type implements the required `BindToValue`, `BindToRef`, or `BindToType` interfaces. |
There was a problem hiding this comment.
May be worth manually wrapping some of this to 80-columns (we don't yet have enforcement from rumdl on this yet)
Assisted-by: Gemini via Antigravity
zygoloid
left a comment
zygoloid
left a comment
There was a problem hiding this comment.
Are we going to want to replace these interfaces with an ext type generic interface at some point? Or do we think the BindToType/BindToValue/BindToRef split will persist?
| A compound member access expression where the first operand is not used for | ||
| `impl` lookup or instance binding is valid, even though the first operand is | ||
| redundant. |
There was a problem hiding this comment.
What does this mean? Do we have a blanket BindToValue(T) impl for all types, that just returns self? If not, what Self, T pairs implement BindToValue and return self?
From the below, I think the above is actually wrong, and what we mean is something much narrower: compound member access where the second operand is a non-method function is valid, and forms a bound member access whose Call does not use self. I think all other forms of vacuous compound member access are still invalid, since we don't implement Bind* for them.
There was a problem hiding this comment.
Updated based on offline discussion.
| // ❌ Error, compound access without impl lookup or instance binding. | ||
| // ⚠️ Suspicious (linter warning), but valid: compound access without impl | ||
| // lookup or instance binding. | ||
| alias X2 = Factory.(Factory.Make); |
There was a problem hiding this comment.
Is this valid? From what we say below, I would conclude:
Factory.Makeis rewritten toFactory.(<Make function found in Factory>).- That uses the
BindToTypefor functions described below, which produces a bound adapter. - Bound adapters don't appear to implement
Bind*, soFactory.(Factory.Make)is invalid.
But it doesn't really seem clear to me what the intent is here.
There was a problem hiding this comment.
Updated based on offline discussion.
| // ❌ Error, compound access without impl lookup or instance binding. | ||
| // ⚠️ Suspicious (linter warning), but valid: compound access without impl | ||
| // lookup or instance binding. | ||
| alias X4 = i32.((i32 as Factory).Make); |
There was a problem hiding this comment.
Similarly I think this is invalid, because (i32 as Factory).Make is rewritten to (i32 as Factory).(<Make found in impl i32 as Factory>), which produces a bound member, and we don't say that that supports further binding.
There was a problem hiding this comment.
Updated based on offline discussion.
The "Primitive member binding interface" section in the current draft of #5389 addresses this. |
Assisted-by: Gemini via Antigravity
Assisted-by: Gemini via Antigravity
|
I'm going to abandon this PR in favor of a proposal to update the member access rules and operations from #3720 . |
3 participants
The new content reflects the new syntax for function declarations (with #7016 that puts
selfin(...)and no use of:!due to #7254 ) and updates theBindToRefinterface to reflect introduction ofrefin #5434 .See #generics-and-templates and discussion on 2026-08-24 for clarifications on the ambiguous points from #3720.
Assisted-by: Gemini via Antigravity