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