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@swift.org(mailto:swift-evolution@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 > <pgwsm...@gmail.com(mailto:pgwsm...@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@swift.org(mailto:swift-evolution@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.f...@devandartist.fritz.box(mailto:etpan.5728ea0f.6ac6505c.f...@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-m3fhrko0vlzytjvyw6y...@public.gmane.org(mailto:swift-evolution-m3fhrko0vlzytjvyw6y...@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-m3fhrko0vlzytjvyw6y...@public.gmane.org(mailto:swift-evolution-m3fhrko0vlzytjvyw6y...@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-m3fhrko0vlzytjvyw6y...@public.gmane.org(mailto:swift-evolution-m3fhrko0vlzytjvyw6y...@public.gmane.org) > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution-m3fhrko0vlzytjvyw6y...@public.gmane.org(mailto:swift-evolution-m3fhrko0vlzytjvyw6y...@public.gmane.org) > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > > > > > > > > > > > ------------- End Message ------------- > > > > > > > > > > > > > > > > > > From James F > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org(mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution