mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 19:40:10 +01:00
Update links to open discussion minutes archives (#1873)
This commit is contained in:
@@ -1863,7 +1863,7 @@ There are some opportunities to improve on and simplify the C++ story:
|
||||
aren't friends of the base class.
|
||||
|
||||
**References:** This was discussed in
|
||||
[the open discussion on 2021-07-12](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr).
|
||||
[the open discussion on 2021-07-12](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr).
|
||||
|
||||
#### Interop with C++ inheritance
|
||||
|
||||
|
||||
@@ -221,6 +221,6 @@ endlessly.
|
||||
See these notes from discussions:
|
||||
|
||||
- [Regular equivalence classes 2021-09-23](https://docs.google.com/document/d/1iyL7ZDfWT6ZmDSz6Fp8MrLcl5nOQc4ItQbeL3QlVXYU/edit#)
|
||||
- [Carbon minutes (rolling): Open discussions: 2021-09-27](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.qh4b1gy7o5el)
|
||||
- [Carbon minutes (rolling): Open discussions: 2021-09-28](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.9a1r39mla9ho)
|
||||
- [Carbon minutes (rolling): Open discussions: 2021-09-27](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.qh4b1gy7o5el)
|
||||
- [Carbon minutes (rolling): Open discussions: 2021-09-28](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.9a1r39mla9ho)
|
||||
- [Regular equivalence classes 2 2021-10-01](https://docs.google.com/document/d/1xGDRSV6q534-CoDZnzuZJmzhty2yPki2ZfDDPLSHYek/edit#)
|
||||
|
||||
+1
-1
@@ -354,5 +354,5 @@ deduced? In particular we were worried about evolution, and allowing users to
|
||||
add functions to an interface as long as they had defaults.
|
||||
|
||||
These problems were discussed in
|
||||
[2021-12-08 open discussion](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.njnqpdcjp5h0).
|
||||
[2021-12-08 open discussion](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.njnqpdcjp5h0).
|
||||
We concluded that we will later find other mechanisms to support this use case.
|
||||
|
||||
+2
-2
@@ -96,8 +96,8 @@ This design was the conclusion of a number of discussions and proposals:
|
||||
[Member lookup in generic and non-generic contexts](https://docs.google.com/document/d/1-vw39x5YARpUZ0uD2xmKepLEKG7_u122CUJ67hNz3hk/edit#)
|
||||
- Nov 4, 2021 document by `josh11b` and `mconst` titled
|
||||
[Carbon: facets exposed from generics](https://docs.google.com/document/d/1C1eIzd6JY0ooE1rDjW1vx7e3i7sgGugCA9bPMRhwWM0/edit#)
|
||||
- [Open discussion on 2021-11-08](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.ec285oam2okw)
|
||||
- [Open discussion 2021-11-11](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.8vuatm82d1mk)
|
||||
- [Open discussion on 2021-11-08](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.ec285oam2okw)
|
||||
- [Open discussion 2021-11-11](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.8vuatm82d1mk)
|
||||
|
||||
The main alternatives we evaluated are summarized below.
|
||||
|
||||
|
||||
+1
-1
@@ -74,7 +74,7 @@ This proposal advances Carbon's goals:
|
||||
Alternatives were considered in:
|
||||
|
||||
- [question-for-leads issue #710: Default comparison for data classes](https://github.com/carbon-language/carbon-lang/issues/710)
|
||||
- [open discussion on 2021-11-29](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.6komy889g3hc)
|
||||
- [open discussion on 2021-11-29](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.6komy889g3hc)
|
||||
|
||||
### Field order is not significant
|
||||
|
||||
|
||||
+1
-1
@@ -164,5 +164,5 @@ as we determined there was a need for the greater expressivity of being able to
|
||||
mark individual items as `final`. This discussion occurred in:
|
||||
|
||||
- [Document examining an extended example using specialization](https://docs.google.com/document/d/1w-kRC338Jc1ibTu7Vf0pOlGKdrpumfz63bzUIxEj9jY/edit)
|
||||
- [2021-11-29 open discussion](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.6komy889g3hc)
|
||||
- [2021-11-29 open discussion](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.6komy889g3hc)
|
||||
- [Carbon's #typesystem channel on Discord](https://discord.com/channels/655572317891461132/708431657849585705/910681126236987495)
|
||||
|
||||
+3
-3
@@ -193,7 +193,7 @@ some experience with it.
|
||||
### Allow function bodies using incomplete interfaces
|
||||
|
||||
We
|
||||
[considered](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.oqmpxtubjmkm)
|
||||
[considered](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.oqmpxtubjmkm)
|
||||
allowing a function definition to use an incomplete interface. One concern was
|
||||
whether the criteria for when the function body depended on something in the
|
||||
interface's definition would be too subtle for developers to reason about. We
|
||||
@@ -216,7 +216,7 @@ declarations for a few reasons:
|
||||
expect to associate with a function.
|
||||
|
||||
This was discussed in
|
||||
[open discussion on 2022-03-14](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.oqmpxtubjmkm)
|
||||
[open discussion on 2022-03-14](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.oqmpxtubjmkm)
|
||||
and
|
||||
[question-for-leads issue #1132](https://github.com/carbon-language/carbon-lang/issues/1132).
|
||||
|
||||
@@ -228,6 +228,6 @@ to deduced parameters for consistency. We may in the future allow some rewrites
|
||||
between equivalent expressions, such as between `Vector(T:! Type)` and
|
||||
`[T:! Type] Vector(T)`, but for now we are starting with the more restrictive
|
||||
rule. This was discussed in
|
||||
[open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.w4zgqvarhnbn)
|
||||
[open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.w4zgqvarhnbn)
|
||||
and in
|
||||
[#syntax channel on Discord](https://discord.com/channels/655572317891461132/709488742942900284/953798170750615622).
|
||||
|
||||
+2
-2
@@ -124,7 +124,7 @@ motivate changes in the future, is to prioritize the different implementations
|
||||
generated by the `like` shortcut separately in `match_first` blocks.
|
||||
|
||||
This was discussed in
|
||||
[open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#).
|
||||
[open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#).
|
||||
|
||||
### Where are the impl definitions from `like` generated?
|
||||
|
||||
@@ -145,7 +145,7 @@ This was discussed in
|
||||
### Support marking interfaces or their members as `external`
|
||||
|
||||
We
|
||||
[discussed on 2022-03-28](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.sk06n1ggoa3o)
|
||||
[discussed on 2022-03-28](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.sk06n1ggoa3o)
|
||||
the idea that operator interfaces might be marked `external`. This would either
|
||||
mean that types would only be able to implement them using `external impl` or
|
||||
that even if they were implemented internally, they would not add the names of
|
||||
|
||||
+14
-14
@@ -51,13 +51,13 @@ Destructors interact with inheritance, which was introduced in proposal
|
||||
|
||||
Destructors were discussed in open discussion on these dates:
|
||||
|
||||
- [2021-07-12](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr)
|
||||
- [2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
|
||||
- [2021-10-04](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.a0rffns9r10n)
|
||||
- [2021-07-12](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr)
|
||||
- [2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
|
||||
- [2021-10-04](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.a0rffns9r10n)
|
||||
discussed not all types being destructible, and that some types are
|
||||
`TriviallyDestructible`
|
||||
- [2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch)
|
||||
- [2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v)
|
||||
- [2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch)
|
||||
- [2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v)
|
||||
|
||||
As part of
|
||||
[proposal 777: Inheritance](https://github.com/carbon-language/carbon-lang/pull/777),
|
||||
@@ -109,11 +109,11 @@ downsides that we ultimately decided were too large:
|
||||
type-of-types were implemented.
|
||||
|
||||
This was considered in the open discussions on
|
||||
[2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
|
||||
[2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
|
||||
and
|
||||
[2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch).
|
||||
[2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch).
|
||||
We decided to go with the proposed approach in
|
||||
[the open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v).
|
||||
[the open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v).
|
||||
|
||||
### Prevent virtual function calls in destructors
|
||||
|
||||
@@ -137,13 +137,13 @@ transitively calls. We would consider this as a potential future extension. As
|
||||
noted in the design, this could be achieved by using the `partial` type.
|
||||
|
||||
This was considered in the open discussions on
|
||||
[2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
|
||||
[2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
|
||||
and
|
||||
[2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch).
|
||||
[2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch).
|
||||
|
||||
### Allow functions to act as destructors
|
||||
|
||||
[We considered, on 2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam),
|
||||
[We considered, on 2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam),
|
||||
how we might support returning a value, for example a failure, from a
|
||||
destructor. This would require that the destructor be called explicitly, rather
|
||||
than implicitly as part of a `Allocator.Delete()` call or a variable leaving
|
||||
@@ -183,7 +183,7 @@ is particularly concerning if whether a type implements a constraint depends on
|
||||
which function is the enclosing scope.
|
||||
|
||||
This was considered in the
|
||||
[open discussion on 2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam).
|
||||
[open discussion on 2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam).
|
||||
|
||||
### Allow multiple conditional destructors
|
||||
|
||||
@@ -270,7 +270,7 @@ does not have a virtual destructor, but may be pointing to a derived value. We
|
||||
as part of
|
||||
[proposal 777: Inheritance](https://github.com/carbon-language/carbon-lang/pull/777).
|
||||
We decided to go with the proposed approach in
|
||||
[the open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v).
|
||||
[the open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v).
|
||||
|
||||
#### Don't distinguish safe and unsafe delete operations
|
||||
|
||||
@@ -299,7 +299,7 @@ This option was considered in the
|
||||
#### Allow final destructors
|
||||
|
||||
One option we
|
||||
[considered early on](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr)
|
||||
[considered early on](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr)
|
||||
for extensible classes with non-virtual destructors, was to require the same
|
||||
thing we do from non-virtual methods. That is, require that the implementation
|
||||
in the base class is appropriate for derived classes. We ultimately decided on a
|
||||
|
||||
Reference in New Issue
Block a user