[swift-evolution] Should we rename "class" when referring to protocol conformance?

[David Sweeris]

On May 2, 2016, at 13:10, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:

>> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I was just thinking that:
>> protocol Foo : reference {}
>> might be more to the point than:
>> protocol Foo : class {}
>> 
>> I know that it’s currently a moot point because classes are the only* reference-semantics type of type in Swift, but it’s conceivable that there might some day be others.
> 
> Functions/closures have reference semantics, but they can't conform to protocols.  Anyway, that's not the important question; the important question is why we would add a new kind of first-class reference type to the language — that can implement class protocols, no less — instead of, at most, calling it a new kind of class.

Dunno, I wasn’t thinking about anything in particular... If there's one thing I've learned on this mailing list, it's that the state of the art WRT to programming languages has changed a lot since I was in school, and, at least to me, it seems like the pace at which it’s changing is increasing as well. This was just an off-the-cuff idea for making the language as future-proof as possible. I don’t have an concrete examples, other than maybe “mixins”. I don’t know anything about them, other than their name seems misspelled to me. Would they even be a separate type of type, or would they get glued onto structs, enums, and classes?

Anyway, I just wanted to raise the issue before Swift 3 comes out, since with v3 we're aiming for source-compatibility going forward.

- Dave Sweeris (who is apparently trying to get the day’s quota for whacky ideas out of the way early :-) )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160502/288b2f42/attachment.html>