[swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Karl Wagner]

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:swift-evolution at swift.org)>  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  swift-evolution at swift.org (mailto:swift-evolution at swift.org)   https://lists.swift.org/mailman/listinfo/swift-evolution
>  
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161021/b6bd85f2/attachment.html>