[swift-evolution] Should we rename "class" when referring to protocol conformance?

James Froggatt conductator at ntlworld.com
Wed May 4 02:37:29 CDT 2016


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> 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> 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>
>> 
>> 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) 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) 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> 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
>> 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/c6618d83/attachment.html>


More information about the swift-evolution mailing list