[swift-evolution] Should we rename "class" when referring to protocol conformance?
Adrian Zubarev
adrian.zubarev at devandartist.com
Wed May 4 06:14:05 CDT 2016
Not sure what to think about the enum cases inside a protocol (if AnyEnum would even exist), it could be a nice addition to the language, but this is an own proposal I guess.
We should start by adding AnyValue protocol to which all value types conforms.
The reason I introduced AnyReference is to distinguish Swift and ObjC classes. The problem with AnyObject is AFAICS that it will bridge the type if possible. I think if you pass a String for AnyObject the type will be bridged to NSString, correct me if I'm wrong. This is what I dislike about the current AnyObject protocol.
Some examples:
protocol A: AnyReference {} // Swift clases == protocol A: class {}
protocol B: AnyValue {} // for all value types; new to the language
protocol C: AnyObject // ObjC classes == protocol C: class {} right now not restricted to ObjC classes
--
Adrian Zubarev
Am 4. Mai 2016 um 09:37:29, James Froggatt via swift-evolution (swift-evolution at swift.org(mailto:swift-evolution at swift.org)) schrieb:
>
> I was thinking that requiring instance properties would mean the value could only be a struct, but rethinking, I realise computed properties would work fine for protocol conformance, so this isn't actually true.
>
> I agree with your support of focusing on interface. Your implications for AnyObject and AnyValue are interesting - that reference-type and value-type semantics are a kind of interface…
>
> One thing occurs to me, thinking about this: what if protocols could require enum cases? This could allow a Failable protocol with .failure(ErrorType), for example; or Nillable, which could implement NilLiteralConvertible for enums with a .none case… I'm not sure, maybe this wouldn't be so useful in practice?
>
> From James F
>
> On 4 May 2016, at 01:01, Patrick Smith <pgwsmith at gmail.com(mailto:pgwsmith at gmail.com)> wrote:
>
> > I can see the benefit for AnyValue, however I think AnyEnum and AnyStruct would be misused.
> >
> > A protocol intended for an enum could be used by a struct that uses an inner enum, for example. If every case had a UUID, then it would be easier to have that a property in a struct, and have the unique associated values for each case in an enum stored in a separate property.
> >
> > Protocols are fantastic I think because they focus on the interface, not the implementation.
> >
> > Better to conform to RawRepresentable (which can be an enum or a struct), or some other protocol.
> > Patrick Smith
> > On May 4 2016, at 7:16 am, James Froggatt via swift-evolution <swift-evolution at swift.org(mailto:swift-evolution at swift.org)> wrote:
> > >
> > > An AnyValue protocol seems long overdue. I'm not sure how useful AnyEnum would be, though I support the idea since it could become useful in the future.
> > >
> > >
> > > ------------ Begin Message ------------
> > > Group: gmane.comp.lang.swift.evolution
> > > MsgID: <etPan.5728ea0f.6ac6505c.f915 at DevAndArtist.fritz.box(mailto:etPan.5728ea0f.6ac6505c.f915 at devandartist.fritz.box)>
> > >
> > >
> > > I’d love to see Swift go in this direction with protocols:
> > >
> > >
> > > +-------+
> > > | Any |
> > > +---+---+
> > > |
> > > +-------------+-------------+
> > > | |
> > > +------+-------+ +-----+----+
> > > | 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-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org(mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg at public.gmane.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-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org(mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg at public.gmane.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-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org(mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org(mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > >
> > >
> > >
> > >
> > > ------------- End Message -------------
> > >
> > >
> > >
> > >
> > >
> > > From James F
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org(mailto:swift-evolution at swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> >
> >
> >
>
> _______________________________________________
> swift-evolution mailing list
> 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/20160504/dcfdffe1/attachment.html>
More information about the swift-evolution
mailing list