From 4b6d19c98d0bf3680b22ec09a892a7a66f1a8c7a Mon Sep 17 00:00:00 2001 From: Slava Pestov Date: Fri, 18 Apr 2025 22:38:00 -0400 Subject: [PATCH] docs: Remove obsolete restriction from LibraryEvolution.rst --- docs/LibraryEvolution.rst | 17 ++++------------- 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/docs/LibraryEvolution.rst b/docs/LibraryEvolution.rst index 50505ef7bb1..ff79d1702c8 100644 --- a/docs/LibraryEvolution.rst +++ b/docs/LibraryEvolution.rst @@ -365,8 +365,7 @@ the following changes are permitted: an existing property (unless the struct is marked ``@frozen``; see below). This is effectively the same as modifying the body of a setter. - Removing any non-ABI-public members, including stored properties. -- Adding a conformance to an ABI-public protocol *that was introduced in the - same release* (see below). +- Adding a conformance to an ABI-public protocol (see below about availability). - Adding or removing a conformance to a non-ABI-public protocol. - Adding ``@dynamicCallable`` to the struct. @@ -382,17 +381,9 @@ target for the library is an error. It is not safe to add or remove ``mutating`` or ``nonmutating`` from a member or accessor within a struct. -If a conformance is added to a type in version 1.1 of a library, it's important -that it isn't accessed in version 1.0. This means that it is only safe to add -new conformances to ABI-public protocols when the protocol is introduced, and -not after. If the protocol comes from a separate module, there is no safe way -to conform to it. - -.. admonition:: TODO - - Coming up with a way to do this, either with availability annotations for - protocol conformances or a way to emit a fallback copy of the conformance - for clients on older library versions to use, is highly desired. +When introducing a new conformance of an existing type to an existing protocol, +it is important to annotate the conformance with availability. This is achieved +by declaring the conformance on an extension and annotating the extension. Methods and Initializers