[Second review] SE-0390: Noncopyable structs and enums

[xwu (Xiaodi Wu)]

@kavon

My interpretation of a protocol, in its purest form, is something that describes the types of a subset of its conformer's non-private members. In this sense, a protocol doesn't tell you about the conformer's in-memory representation (structs and classes can conform) or what private members it has (implementation detail). Conceptually, protocol requiring a private member to exist doesn't make sense, as that member is not going to be accessible via the protocol. An empty protocol doesn't tell you anything about its conforming types; it just creates a new type functionally equivalent to Any.

We have always insisted, for the purpose of Swift Evolution at least, that a protocol is something that one can employ in writing a useful generic algorithm; it has semantic requirements in addition (or even in spite of not having) syntactic requirements.

With this criterion, we've justified why Error is a protocol (even as it has no required members without defaulted implementations), and why we describe Sendable as a "marker" protocol. It is without a doubt that Sendable is a very useful generic constraint.

We've also used this criterion to decide what's not to be a protocol in the development of the hierarchy of numeric protocols—because protocols don't abstract over just "bags of syntax" (i.e., just some arbitrary shared subset of types' public members), we rejected having things like Divisible that would glom together floating-point and integer division, or Addable that could arguably even include String, etc. (Namely, it would be more likely than not that an algorithm which divides without knowing whether it's integer division or floating-point division is just wrong rather than a useful operation, and it would be bonkers to write something like a + b in a generic context that either appends to a string or adds to an integer and doesn't care which it's doing.) *

Along these lines, should (and I expect it would) Copyable be justified as an addition to the language independent of ~Copyable, it would be in the context of a generic constraint so that we can usefully write algorithms that operate on values of any copyable type and exclude noncopyable ones; that, in and of itself, justifies its being a protocol in the way we have always thought of it here.

* Application of this criterion goes some way to rationalizing why @propertyWrapper and @resultBuilder are spelled as attributes and not conformances to some hypothetical PropertyWrapper and ResultBuilder. All result builders, for example, will have some subset of build* functions (they share overlapping subsets of members), but it is hard to imagine someone writing a useful algorithm generic over all result builders (outside of a code generation or reflection context, perhaps, but those have dedicated libraries to support those use cases that are different in kind from what we're talking about here).