Restricting Swift protocols to classes only, because the protocol (by definition) has reference semantics: thoughts?
Conversation
making identity a requirement of the protocol is useful, but I’d often prefer that be reified.
2
1
I don’t actually rely upon it having identity. The whole thing was just: should implementors be forced into a reference type?
1
Ah; probably no.
1
Even if the protocol describes something that should rightfully have reference semantics? Using a struct for that seems wrong.
1
1
I’m having trouble thinking about this without an example.
1
For example, a protocol that describes a Future. Should implementors be required to be classes?
1
You could write a struct Promise that incorporates a GCD queue or something, but is that even legit?
1
Yes, absolutely. That’s exactly what I was writing about here:
intersections.tumblr.com/post/996340847
3
Replying to
Agreed with Rob here. If the implementor wants to use a thin struct wrapping a reference, that's on them.
Replying to
2
1
Show replies