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 <[email protected]> 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 >> <[email protected]> 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: <[email protected]> >> >> 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 >> ([email protected]) 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 >> ([email protected]) 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> ------------- End Message ------------- >> >> From James F >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
