<html><head></head><body><div>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.</div><div><br></div><div>We should start by adding AnyValue protocol to which all value types conforms.</div>
<div><br></div>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.<div><br></div><div>Some examples:</div><div><br></div><div>protocol A: AnyReference {} // Swift clases == protocol A: class {}</div><div><br></div><div>protocol B: AnyValue {} // for all value types; new to the language</div><div><br></div><div>protocol C: AnyObject // ObjC classes == protocol C: class {} right now not restricted to ObjC classes<br> <br><div class="bloop_sign"><div>-- <br>Adrian Zubarev</div></div> <p class="gmail_quote" style="color:#000;">Am 4. Mai 2016 um 09:37:29, James Froggatt via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="gmail_quote"><span><div dir="auto"><div></div><div>
<title></title>
<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>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote>
</div></body></html>