Update links to open discussion minutes archives (#1873)

This commit is contained in:
josh11b
2022-08-01 16:46:19 -07:00
committed by GitHub
parent 8b5c13e8de
commit 6210353dfe
9 changed files with 27 additions and 27 deletions
+1 -1
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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
View File
@@ -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