Address feedback, delegating expand api work to a future proposal

Author: josh11b

proposals/p3720.md

@@ -30,8 +30,10 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Binding to the members of another type](#binding-to-the-members-of-another-type)
     -   [Other uses of `extend api`](#other-uses-of-extend-api)
     -   [C++ operator overloading](#c-operator-overloading)
+-   [Future work](#future-work)
     -   [Future: tuple indexing](#future-tuple-indexing)
     -   [Future: properties](#future-properties)
+    -   [Future: building block for language features such as API extension](#future-building-block-for-language-features-such-as-api-extension)
 -   [Rationale](#rationale)
 -   [Alternatives considered](#alternatives-considered)
     -   [Swap the bind interface parameters](#swap-the-bind-interface-parameters)
@@ -140,6 +142,9 @@ interface TypeBind(T:! type) {
 }
 ```
 
+> **Note:** `TypeBind` is its own binding interface since the members of a type
+> are defined by their values, not by their type.
+
 The other member access operators -- `x.y`, `x->y`, and `x->(y)` -- are defined
 by how they rewrite into the `x.(y)` form using these two rules:
 
@@ -278,36 +283,14 @@ How does this arise?
 >
 > Note that if `M` is an overloaded name, it could be an instance member in some
 > cases and a non-instance member in others, depending on the arguments passed.
-> This is another reason to delegate this to linters on a best-effort error
-> basis analyzing a whole expression, rather than a strict rule just about
+> This is another reason to delegate this to linters analyzing a whole
+> expression on a best-effort basis, rather than a strict rule just about
 > binding.
 
-The binding operators are defined using three dedicated interfaces:
-
-```carbon
-// For value `x` with type `T` and `y` of type `U`,
-// `x.(y)` is `y.((U as ValueBind(T)).Op)(x)`
-interface ValueBind(T:! type) {
-  let Result:! type;
-  fn Op[self: Self](x: T) -> Result;
-}
-
-// For reference expression `var x: T` and `y` of type `U`,
-// `x.(y)` is `*y.((U as RefBind(T)).Op)(&x)`
-interface RefBind(T:! type) {
-  let Result:! type;
-  fn Op[self: Self](p: T*) -> Result*;
-}
-
-// For a facet value `T`, `y` of type `U`,
-// `T.(y)` is `y.((U as TypeBind(T)).Op)()`.
-interface TypeBind(T:! type) {
-  let Result:! type;
-  fn Op[self: Self]() -> Result;
-}
-```
-
-These binding operations are implemented for the types of the class members:
+The binding operators are defined using three dedicated interfaces --
+`ValueBind`, `RefBind`, and `TypeBind` --
+[as defined in the "proposal" section](#proposal). These binding operations are
+implemented for the types of the class members:
 
 ```carbon
 impl __TypeOf_C_F as ValueBind(C)
@@ -875,12 +858,18 @@ class Box(T:! type) {
 ```
 
 This means that lookup into `Box(T)` also looks in the type `T` for members. In
-this way, `b.Search` will find `b.(String.Search)`. The general rule for
-`extend`, which we apply here as well, is that if lookup into `Box(T)` succeeds,
-then that result is used and no lookup into `T` is performed. The extended type
-must be complete. If a class uses `extend` more than once, and finds the same
-name more than once, that is an ambiguity error that needs to be resolved by
-qualifying the name on use.
+this way, `b.Search` will find `b.(String.Search)`. The extended type is
+required to be complete at the point of the `extend api` declaration, so these
+lookups into `T` can succeed.
+
+The general rule for resolving ambiguity for `extend`, which we apply here as
+well, is that if lookup into `Box(T)` succeeds, then that result is used and no
+lookup into `T` is performed. If a class uses `extend` more than once, and finds
+the same name more than once, that is an ambiguity error that needs to be
+resolved by qualifying the name on use.
+
+> **TODO:** Are these the right rules in the context of API evolution? See
+> [comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1527084183).
 
 > **Note:** This is an alternative to defining an `alias` for each member of the
 > extended type. This avoids having to repeat them, which is both lengthy and
@@ -892,7 +881,12 @@ Like other uses of `extend`, an `extend api` declaration do not have access
 control modifiers and only operate on public names.
 
 > **Future:** We might want `extend api` to also get (some) interface
-> implementations, like `extend base` does.
+> implementations, like `extend base` does. Or this may be provided by a
+> different mechanism, for example that allows customization of impl binding by
+> implementing an interface. See
+> [this comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1527083149)
+> and
+> [2024-03-18 open discussion](https://docs.google.com/document/d/1s3mMCupmuSpWOFJGnvjoElcBIe2aoaysTIdyczvKX84/edit?resourcekey=0-G095Wc3sR6pW1hLJbGgE0g&tab=t.0#heading=h.23p8d6pqg1qp).
 
 #### Binding to the members of another type
 
@@ -941,6 +935,18 @@ With these two ingredients, `b.Search(32)` is equivalent to
 
 ### Other uses of `extend api`
 
+> TODO: Give the example of reference library type from
+> [this comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1513712572).
+
+> TODO: Show how to model other language constructs with `extend api`, custom
+> binding, and implicit (or explicit) conversions, as described in
+> [this comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1527089564):
+>
+> -   other uses of `extend`,
+> -   inheritance,
+> -   virtual dispatch, and
+> -   mixins.
+
 The [`extend api` mechanism](#extend-api), allowing lookup to find names from
 another type, has other uses beyond [member forwarding](#member-forwarding).
 
@@ -1058,6 +1064,8 @@ just for C++ interop that invokes the C++ arrow operator, such as
 and in
 [a comment on this proposal](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1507917882).
 
+## Future work
+
 ### Future: tuple indexing
 
 We can reframe the use of the compound member access syntax for tuple fields as
@@ -1098,6 +1106,12 @@ interfaces. The compiler would try them in a specified order and use the one it
 found first. This has the downside of the possibility of different behavior in a
 checked generic context where only some of the implementations are visible.
 
+### Future: building block for language features such as API extension
+
+We should be able to express other language features, such as API extension, in
+terms of customized binding, plus possibly some new language primitives. This
+should be explored in a future proposal.
+
 ## Rationale
 
 This proposal is about: