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.
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:
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.
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
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".
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 :-) )
···
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.
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
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.
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.