IIRC, the reason we have "class" there is for the optimiser, so it can optimise for the protocol being satisfied by a reference-counted type. Classes are semantically unique from values because they have identity, which is also something a protocol might want to codify.
There may be some optimisation gains by requiring all conformers to be values, but I struggle to think of why you might want to codify that a conformer should not have identity. Personally I don't really like this asymmetry in the language either, and would support changes to make these two elements more explicit. For example, a magic "hasIdentity" protocol which is automatically satisfied only by classes, and moving the optimisation guides to usage site (e.g. when declaring a variable of type MyProto, I could declare it of type AnyClass<MyProto> or AnyValue<MyProto> instead, to annotate this specific instance as being refcountable or not, without making such optimisation hints part of the MyProto definition) - Karl > > On Oct 21, 2016 at 8:39 am, <Mike Kasianowicz via swift-evolution > (mailto:[email protected])> wrote: > > > > Currently protocols can have the class constraint: > protocol MyProtocol : class {} > > > > It would be (a) intuitive and (b) useful to allow such things as: > > protocol Model : struct {} or protocol Event : enum {} > > > > These types of restrictions can help prevent accidental anti-patterns or > misuse of APIs. > > > > Seems simple and non-controversial... right? > > > > [Note: I'd like to see even more heavy-handed protocol restrictions in the > future. For example, a protocol describing an enum with a common case, or > a struct with no reference members. Great stuff for defensively coding APIs.] > > _______________________________________________ swift-evolution mailing list > [email protected] (mailto:[email protected]) > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
