<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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…</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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?</div><div id="AppleMailSignature"><br>From James F</div><div><br>On 4 May 2016, at 01:01, Patrick Smith <<a href="mailto:pgwsmith@gmail.com">pgwsmith@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>I can see the benefit for AnyValue, however I think AnyEnum and AnyStruct would be misused.<div><div><br></div><div>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.</div><div><br></div><div>Protocols are fantastic I think because they focus on the interface, not the implementation.</div><div><br></div><div>Better to conform to RawRepresentable (which can be an enum or a struct), or some other protocol.</div><br><!-- <signature> --><b>Patrick Smith</b><br><!-- </signature> --></div><div class="gmail_quote">
On May 4 2016, at 7:16 am, James Froggatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>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.</p>
<p>------------ Begin Message ------------ <br>Group: gmane.comp.lang.swift.evolution <br>MsgID: <<a href="mailto:etPan.5728ea0f.6ac6505c.f915@devandartist.fritz.box">etPan.5728ea0f.6ac6505c.f915@DevAndArtist.fritz.box</a>> </p>
<p>I’d love to see Swift go in this direction with protocols:</p>
<p> +-------+<br> | Any |<br> +---+---+<br> |<br> +-------------+-------------+<br> | |<br> +------+-------+ +-----+----+<br> | AnyReference | | AnyValue |<br> +------+-------+ +-----+----+<br> | |<br>+--------+---------+ ....................................<br>| AnyObject (ObjC) | : Optionally Swift could also have :<br>+------------------+ : | :<br> : +-------+--------+ :<br> : | | :<br> : +----+----+ +-----+-----+ :<br> : | AnyEnum | | AnyStruct | :<br> : +----+----+ +-----+-----+ :<br> ....................................</p>
<p>-- <br>Adrian Zubarev<br>Sent with Airmail</p>
<p>Am 3. Mai 2016 bei 18:42:15, Adrian Zubarev via swift-evolution (<a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a>) schrieb:</p>
<p>+1 Yes please, get rid of the `class` keyword from protocols already and replace it with better implicit protocols.</p>
<p>I posted the idea two weeks ago, but no one answered to it: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html</a></p>
<p>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.</p>
<p>-- <br>Adrian Zubarev<br>Am 2. Mai 2016 um 15:55:15, David Sweeris via swift-evolution (<a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a>) schrieb:</p>
<p>I was just thinking that:<br>protocol Foo : reference {}<br>might be more to the point than:<br>protocol Foo : class {}</p>
<p>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.</p>
<p>- Dave Sweeris</p>
<p>* 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.<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
<p></p>
<p>------------- End Message ------------- </p>
<p></p>
<p>From James F<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote>
</div></div></blockquote></body></html>