Should we rename "class" when referring to protocol conformance?


(David Sweeris) #1

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. Anyway, I’m not saying it’s a big deal or anything, I’m just trying to think of any source-breaking changes we might want to make before Swift 3 drops, and this seems like an easy one.

- Dave Sweeris

* I’m not actually sure this is true. I have a very vague recollection about some protocols getting reference semantics in certain circumstances, but the memory is so hazy I’m not sure I trust it. Also I can’t remember if the “indirect” keyword in enums affects the semantics.


Memory initialization and deinitialization best practices
(John McCall) #2

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.

Anyway, I’m not saying it’s a big deal or anything, I’m just trying to think of any source-breaking changes we might want to make before Swift 3 drops, and this seems like an easy one.

- Dave Sweeris

* I’m not actually sure this is true. I have a very vague recollection about some protocols getting reference semantics in certain circumstances, but the memory is so hazy I’m not sure I trust it. Also I can’t remember if the “indirect” keyword in enums affects the semantics.

Other than permitting otherwise-infinite types, no.

John.

···

On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:


(Dave Abrahams) #3

Personally I have always felt “class” was an oddball special case here
that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

···

on Mon May 02 2016, David Sweeris <swift-evolution@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. Anyway, I’m not saying it’s a big deal or anything, I’m just
trying to think of any source-breaking changes we might want to make before
Swift 3 drops, and this seems like an easy one.

- Dave Sweeris

* I’m not actually sure this is true. I have a very vague recollection about
some protocols getting reference semantics in certain circumstances, but the
memory is so hazy I’m not sure I trust it. Also I can’t remember if the
“indirect” keyword in enums affects the semantics.

--
Dave


(Adrian Zubarev) #4

+1 Yes please, get rid of the `class` keyword from protocols already and replace it with better implicit protocols.

I posted the idea two weeks ago, but no one answered to it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html

Replacing `class` with something like `protocol AnyReference` is the first step to add a few more implicit protocols like `AnyValue` to Swift. We could build value or reference type specific libraries and overload correctly.

···

--
Adrian Zubarev

Am 2. Mai 2016 um 15:55:15, David Sweeris via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

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. Anyway, I’m not saying it’s a big deal or anything, I’m just trying to think of any source-breaking changes we might want to make before Swift 3 drops, and this seems like an easy one.

- Dave Sweeris

* I’m not actually sure this is true. I have a very vague recollection about some protocols getting reference semantics in certain circumstances, but the memory is so hazy I’m not sure I trust it. Also I can’t remember if the “indirect” keyword in enums affects the semantics. _______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #5

I've been thinking of a different name as well — but I was concerned by the fact that "class" is lowercase, while all "regular" types start uppercase…
I'd prefer "Class" or "Reference" over "reference".

Tino


(David Sweeris) #6

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 :slight_smile: )

···

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

On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.


(Adrian Zubarev) #7

I’d love to see Swift go in this direction with protocols:

···
               \+\-\-\-\-\-\-\-\+
               &gt;  Any  |
               \+\-\-\-\+\-\-\-\+
                   &gt;
     \+\-\-\-\-\-\-\-\-\-\-\-\-\-\+\-\-\-\-\-\-\-\-\-\-\-\-\-\+
     &gt;                           &gt;

+------+-------+ +-----+----+
> AnyReference | | AnyValue |
+------+-------+ +-----+----+
> >
+--------+---------+ ....................................

AnyObject (ObjC) | : Optionally Swift could also have :

+------------------+ : | :
: +-------+--------+ :
: | | :
: +----+----+ +-----+-----+ :
: | AnyEnum | | AnyStruct | :
: +----+----+ +-----+-----+ :
....................................

--
Adrian Zubarev
Sent with Airmail

Am 3. Mai 2016 bei 18:42:15, Adrian Zubarev via swift-evolution (swift-evolution@swift.org) schrieb:

+1 Yes please, get rid of the `class` keyword from protocols already and replace it with better implicit protocols.

I posted the idea two weeks ago, but no one answered to it: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html

Replacing `class` with something like `protocol AnyReference` is the first step to add a few more implicit protocols like `AnyValue` to Swift. We could build value or reference type specific libraries and overload correctly.

--
Adrian Zubarev
Am 2. Mai 2016 um 15:55:15, David Sweeris via swift-evolution (swift-evolution@swift.org) schrieb:

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. Anyway, I’m not saying it’s a big deal or anything, I’m just trying to think of any source-breaking changes we might want to make before Swift 3 drops, and this seems like an easy one.

- Dave Sweeris

* I’m not actually sure this is true. I have a very vague recollection about some protocols getting reference semantics in certain circumstances, but the memory is so hazy I’m not sure I trust it. Also I can’t remember if the “indirect” keyword in enums affects the semantics.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jesse Squires) #8

Personally I have always felt “class” was an oddball special case here

that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

+1

Repurposing the `class` keyword to constrain a protocol to reference types
has always felt awkward, out-of-place, and inconsistent with the rest of
the language. I would love to see this changed to `AnyObject` as Dave
suggests.

Given all of the other great refinements for language consistency that have
been proposed and accepted for Swift 3, the awkwardness of using `class`
here is even greater than before.

Jesse

···

On Tue, May 3, 2016 at 11:06 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Mon May 02 2016, David Sweeris <swift-evolution@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. Anyway, I’m not saying it’s a big deal or anything,
I’m just
> trying to think of any source-breaking changes we might want to make
before
> Swift 3 drops, and this seems like an easy one.
>
> - Dave Sweeris
>
> * I’m not actually sure this is true. I have a very vague recollection
about
> some protocols getting reference semantics in certain circumstances, but
the
> memory is so hazy I’m not sure I trust it. Also I can’t remember if the
> “indirect” keyword in enums affects the semantics.

Personally I have always felt “class” was an oddball special case here
that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jesse Squires

*blog* | jessesquires.com <http://www.jessesquires.com>
*github* | github.com/jessesquires <http://www.github.com/jessesquires>
*hexedbits* | hexedbits.com <http://www.hexedbits.com>


(Basem Emara) #9

How about mutating keyword just like func's:

mutating protocol Foo {…}

Isn’t that what the current “class” keyword is trying to indicate? It feels awkward that a protocol would inherit from a reference type when just looking at the syntax, whether it be class, AnyObject, etc.

···

On May 5, 2016, at 10:52 AM, Jesse Squires via swift-evolution <swift-evolution@swift.org> wrote:

> Personally I have always felt “class” was an oddball special case here
that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

+1

Repurposing the `class` keyword to constrain a protocol to reference types has always felt awkward, out-of-place, and inconsistent with the rest of the language. I would love to see this changed to `AnyObject` as Dave suggests.

Given all of the other great refinements for language consistency that have been proposed and accepted for Swift 3, the awkwardness of using `class` here is even greater than before.

Jesse

On Tue, May 3, 2016 at 11:06 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Mon May 02 2016, David Sweeris <swift-evolution@swift.org <mailto:swift-evolution@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. Anyway, I’m not saying it’s a big deal or anything, I’m just
> trying to think of any source-breaking changes we might want to make before
> Swift 3 drops, and this seems like an easy one.
>
> - Dave Sweeris
>
> * I’m not actually sure this is true. I have a very vague recollection about
> some protocols getting reference semantics in certain circumstances, but the
> memory is so hazy I’m not sure I trust it. Also I can’t remember if the
> “indirect” keyword in enums affects the semantics.

Personally I have always felt “class” was an oddball special case here
that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Jesse Squires

blog | jessesquires.com <http://www.jessesquires.com/>
github | github.com/jessesquires <http://www.github.com/jessesquires>
hexedbits | hexedbits.com <http://www.hexedbits.com/>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution