Delete content moved to carbon-language#3802

josh11b · josh11b · commit 8df97205293c · 2024-03-20T23:23:08.000Z
diff --git a/proposals/p3720.md b/proposals/p3720.md
@@ -25,10 +25,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [C++ pointer to member](#c-pointer-to-member)
     -   [Instance interface members](#instance-interface-members)
     -   [Non-instance interface members](#non-instance-interface-members)
-    -   [Member forwarding](#member-forwarding)
-        -   [`extend api`](#extend-api)
-        -   [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)
@@ -39,17 +35,14 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Swap the bind interface parameters](#swap-the-bind-interface-parameters)
     -   [Reference binding produces a value that wraps a pointer](#reference-binding-produces-a-value-that-wraps-a-pointer)
     -   [Separate interface for compile-time binding instead of type binding](#separate-interface-for-compile-time-binding-instead-of-type-binding)
-    -   [Allow `extend api` of an incomplete type](#allow-extend-api-of-an-incomplete-type)
-    -   [Make some name resolutions cases unambiguous with `extend api`](#make-some-name-resolutions-cases-unambiguous-with-extend-api)
 
 <!-- tocstop -->
 
 ## Abstract
 
 Define the binding operation used to compute the result of `x.y`, `p->y`,
 `x.(C.y)`, and `p->(C.y)` as calling a method from user-implementable
-interfaces. Also allow classes to `extend api` other classes, for forwarding use
-cases.
+interfaces.
 
 ## Problem
 
@@ -157,43 +150,6 @@ by how they rewrite into the `x.(y)` form using these two rules:
         the `T.(`\_\_\_`)` form.
 -   `x->y` and `x->(y)` are interpreted as `(*x).y` and `(*x).(y)` respectively.
 
-In addition, we propose adding a declaration in a type definition to find names
-defined in another type, [`extend api T`](#extend-api):
-
-```carbon
-class Extended {
-  fn F[self: Self]();
-  fn G[self: Self]();
-}
-
-class Extending {
-  fn G[self: Self]();
-  extend api Extended;
-  impl as ImplicitAs(Extended);
-}
-
-var e: Extending;
-```
-
-This means that lookup into `Extending` also looks in the type `Extended` for
-members. In this way, `e.F` will find `e.(Extended.F)`. Note that does not make
-`e.F()` actually work unless `Extended.F` was somehow legal to call on an value
-of type `Extending`. In the example, this is accomplished by defining an
-implicit conversion from `Extending` to `Extended`.
-
-`extend api T` is equivalent to defining an `alias` for every member of `T` that
-doesn't have a conflicting name. This means `Extending` is equivalent to:
-
-```carbon
-class Extending {
-  fn G[self: Self]();
-  alias F = Extended.F;
-  impl as ImplicitAs(Extended);
-}
-```
-
-This is used for [member forwarding use cases](#member-forwarding).
-
 ## Details
 
 To use instance members of a class, we need to go through the additional step of
@@ -798,253 +754,13 @@ Which calls the above implementation that calls `Fireworks()`.
 > result type. Furthermore, we want `TypeBind` implementation no matter which
 > facet of the type is used in the code.
 
-### Member forwarding
-
-Consider a class that we want to act like it has the members of another type.
-For example, a type `Box(T)` that has a pointer to a `T` object allocated on the
-heap:
-
-```carbon
-class Box(T:! type) {
-  var ptr: T*;
-  // ???
-}
-```
-
-`Box(T)` should act like it has all the members of `T`:
-
-```carbon
-class String {
-  fn Search[self: Self](c: u8) -> i32;
-}
-var b: Box(String) = ...;
-var position: i32 = b.Search(32);
-```
-
-There are two ingredients to make this work:
-
--   We need some way to make `b.Search` be equivalent to `b.(String.Search)` not
-    `b.(Box(String).Search)`.
--   We need the act of binding a method of `String` to a `Box(String)` value
-    work by dereferencing the pointer `b.ptr`.
-
-#### `extend api`
-
-For the first ingredient, we need a way to customize
-[simple member access](/docs/design/expressions/member_access.md) for the class
-`Box(T)`. Normally simple member access on a value like `b`
-[looks in the type of `b`](/docs/design/expressions/member_access.md#values).
-However, types can designate other entities to also look up in using the
-`extend` keyword (see [proposal #2760](/proposals/p2760.md#proposal)):
-
--   `extend impl as I` adds lookup into the implementation of an interface `I`.
--   `extend base: B` adds lookup into the base class `B`.
--   `extend adapt C` adds lookup into the adapted class `C`.
--   [mixins are also planning](/proposals/p2760.md#future-work-mixins) on using
-    an `extend` syntax
-
-The natural choice is to add another way of using `extend` with consistent
-lookup rules as the other uses of `extend`, with conflicts handled as determined
-by leads issues
-[#2355](https://github.com/carbon-language/carbon-lang/issues/2355) and
-[#2745](https://github.com/carbon-language/carbon-lang/issues/2745). I propose
-`extend api T`:
-
-```carbon
-class Box(T:! type) {
-  var ptr: T*;
-  extend api T;
-}
-```
-
-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 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
-> could get out of sync as the class evolves. The `extend api` approach works
-> even if, as in this example, we don't know the names of the members of the
-> type being extended.
-
-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. 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
-
-For the second ingredient, the binding interfaces already provide everything
-needed, we just need to make a parameterized implementation of them:
-
-```carbon
-impl forall [T:! type, U:! ValueBind(T)]
-    U as ValueBind(Box(T)) where .Result = U.Result {
-  fn Op[self: Self](x: Box(T)) -> Result {
-    // Uses `ValueBind(T).Op` based on type of `U`.
-    return self.Op(*x.ptr);
-
-    // NOT `return x.ptr->(self)` since that attempts
-    // to do reference binding not value binding.
-  }
-}
-
-impl forall [T:! type, U:! RefBind(T)]
-    U as RefBind(Box(T)) where .Result = U.Result {
-  fn Op[self: Self](p: Box(T)*) -> Result* {
-    return self.Op(p->ptr);
-    // Or equivalently:
-    // return p->ptr->(self);
-  }
-}
-```
-
-A few observations:
-
--   These declarations use `Box` to satisfy the orphan rule, and so this
-    approach only works with `Box(T)` values, not types that can implicitly
-    convert to `Box(T)`.
--   The implementation of the `Op` method is where we follow the pointer member
-    `ptr` of `Box(T)` to get a `T` value that is compatible with the member
-    being bound. This resolves the type mismatch that is introduced by allowing
-    name resolution to find another type's members.
--   We have to be a little careful in the implementation of `ValueBind(Box(T))`
-    to still use value binding even when we get a reference expression from
-    dereferencing the pointer `ptr`.
-
-With these two ingredients, `b.Search(32)` is equivalent to
-`b.(String.Search)(32)`, which is then equivalent to
-`b.ptr->(String.Search)(32)` or `b.ptr->Search(32)` (since `b.ptr` has type
-`String*`).
-
-### 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).
-
-A class could extend the API of a class it implicitly converts to, see
-[inheritance and other implicit conversions](#inheritance-and-other-implicit-conversions).
-For example, imagine we have a class representing an integer in a restricted
-range that can implicitly convert to an integer value.
-
-```carbon
-class InRange(Low:! i32, High:! i32) {
-  var value: i32;
-  impl as ImplicitAs(i32) {
-    fn Convert[self: Self]() -> i32 { return self.value; }
-  }
-  extend api i32;
-}
-```
-
-By including `extend api i32`, `InRange` gains support for any non-`addr`
-methods on `i32`, like perhaps `Abs`.
-
-Or a class could have members specifically intended for use by another class, as
-[extension methods](https://github.com/carbon-language/carbon-lang/issues/1345)
--- effectively acting as mixin except it can't add member variables.
-
-The examples so far use `extend api` between two classes, but we also allow it
-with interfaces and named constraints.
-
-For example, a class can `extend api` of an interface it
-[conditionally conforms to](/docs/design/generics/details.md#conditional-conformance),
-as in:
-
-```carbon
-interface A {
-  fn F();
-}
-class C(T:! type) {
-  extend api A;
-}
-impl C(i32) as A { fn F() { ... } }
-```
-
-Here, the class `C(T)` implements `A` for some values of `T`, such as `i32`.
-Rather than manually individually aliasing the members of `A` in `C`, to make
-them available as part of the API of `C`, so that `C(i32).F()` is valid, an
-`extend api` declaration includes all of them at once.
-
-Another use case is that an interface can `extend api` of another interface. In
-this example,
-
-```carbon
-interface A {
-  fn F();
-}
-interface B {
-  extend api A;
-  fn G();
-}
-```
-
-`B.F` would be an alias for `A.F`, but without any implied
-`require Self impls A`, in contrast with a plain `extend A`. So `extend I;` is
-equivalent to `require Self impls I; extend api I;`.
-
-Lastly, an interface could `extend api` a class. This could be done to add
-something that acts like `final` functions to the interface, using
-[extension methods](https://github.com/carbon-language/carbon-lang/issues/1345),
-as in:
-
-```carbon
-class Helpers {
-  fn F[T:! type, self: T]() { DoStuffWith(self); }
-  // ...
-}
-interface Iface {
-  extend api Helpers;
-  fn G();
-  // ...
-}
-class C {
-  extend impl as Iface;
-}
-fn Test(c: C) {
-  // Calls Helpers.F from extended class Helpers
-  c.F();
-}
-```
-
-Unlike `final` functions in an interface, this approach defines all the helpers
-in a separate entity that could be used to extend more than one type.
-
 ### C++ operator overloading
 
-C++ does not support a feature like `extend api` nor does it support customizing
-the behavior of `x.y`. It does support customizing the behavior of `operator*`
-and `operator->` which is frequently used to support smart pointers and
-iterators. There is, however, nothing restricting the implementations of those
-two operators to be consistent, so that `(*x).y` and `x->y` are the same.
+C++ does not support customizing the behavior of `x.y`. It does support
+customizing the behavior of `operator*` and `operator->` which is frequently
+used to support smart pointers and iterators. There is, however, nothing
+restricting the implementations of those two operators to be consistent, so that
+`(*x).y` and `x->y` are the same.
 
 Carbon instead will only have a single interface for customizing dereference,
 corresponding to `operator*` not `operator->`. All uses of `x->y` will be
@@ -1263,28 +979,3 @@ types, not all compile-time values. The
 was that types are special because their members are defined by their values,
 not by their type
 ([which is always `type`](https://github.com/carbon-language/carbon-lang/pull/2360)).
-
-### Allow `extend api` of an incomplete type
-
-We considered allowing `extend api T` with `T` an incomplete type. This has some
-disadvantages:
-
--   `T` must be complete before the first time name lookup into it is performed.
-    Actually avoiding name lookup into `T` is very difficult, though, since you
-    need to be very careful to fully qualify (using `package.`) names used in
-    the class definition, except those names defined within the class itself.
--   Other uses of `extend`, such as `extend base: T` require the type to be
-    complete.
--   We did not have a use case for using `extend api` with an incomplete type.
--   Requiring complete types forces types to be defined in a total order,
-    preventing cycles (`A` extends `B` extends `C` extends `A`).
-
-This was discussed in the
-[proposal review](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1507988547)
-and
-[the #typesystem channel on Discord](https://discord.com/channels/655572317891461132/708431657849585705/1217499991329738852).
-
-### Make some name resolutions cases unambiguous with `extend api`
-
-TODO: See
-[comment on #3720](https://github.com/carbon-language/carbon-lang/pull/3720/files#r1513671030)
