<div dir="ltr">I agree with zhaoxin, <font face="monospace, monospace">self.Marriageable.ring</font> doesn't seem to provide the same interface as the protocol. It is similar to how it would be done with existing swift code, and doesn't risk sharing a name with static properties and typealiases on the type.<div><br></div>Something we still need to handle though is associated and Self type requirements.<div> * Should you be able to apply similar namespaces to an associated type?</div><div> * How do you cast to a protocol with an associated type?<br><div><br></div><div>For example:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">protocol P1</font><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace">{</span></div><div><font face="monospace, monospace"> typealias Element</font></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace"> func get() -> Element</font></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace">protocol P2 {</font></div><div><font face="monospace, monospace"> typealias Element</font></div><div><font face="monospace, monospace"> func get() -> Element<br></font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace">struct X: P1, P2 {</font></div><div><font face="monospace, monospace"> typealias P1.Element = Int</font></div><div><font face="monospace, monospace"> typealias P2.Element = Float</font></div><div><font face="monospace, monospace"> func get() -> P1.Element { fatalError() }<br></font></div><div><span style="font-family:monospace,monospace"> func get() -> P2.Element { fatalError() }</span><font face="monospace, monospace"><br></font></div><div><span style="font-family:monospace,monospace">}</span><br></div><div><div><font face="monospace, monospace">struct Y: P1, P2 {</font></div><div><font face="monospace, monospace"> typealias Element = Int</font></div><div><font face="monospace, monospace"> func P1.get() -> Element { fatalError() }<br></font></div><div><font face="monospace, monospace"> func P2.get() -> Element { fatalError() }<br></font></div><div><font face="monospace, monospace">}</font></div></div></blockquote></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><font face="monospace, monospace">let e1 = (x as P1).get()</font></div></div></div><div><font face="monospace, monospace">let e2 = (x as P2).get()</font><br></div></blockquote><div><div><div><div><br></div></div></div></div><div>There will be errors on e1 and e2 like this:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><b>protocol 'P1' can only be used as a generic constraint because it has Self or associated type requirements</b></p></div></blockquote><div><br></div>You may be able to get around it with a generic function, but the ugliness of that solution should be considered in our choices for this proposal.<div><br></div><div>It would be nice (in general) to be able to do this:<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">let e3 = (x as P1</font><span style="font-family:monospace,monospace"><Int></span><span style="font-family:monospace,monospace">).get()</span></div></div><div><div><font face="monospace, monospace">let e4 = (x as P2</font><span style="font-family:monospace,monospace"><Float></span><span style="font-family:monospace,monospace">).get()</span></div></div></blockquote><div><div><br></div></div><div>However it's unclear what type e3 and e4 should be, there's currently no support for automatic synthesis of type-erased structures, and there's no meta-type I know of that can stand-in.</div><div><br></div><div>Perhaps associated and Self type requirements are out-of-scope of this proposal, but I thought it was worth mentioning.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 11, 2016 at 4:26 PM, 肇鑫 <span dir="ltr"><<a href="mailto:owenzx@gmail.com" target="_blank">owenzx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I don't think self.Marriageable.ring is a good idea. As self.Type conforms Marriageable protocol, and a protocol is not a property of a class/struct/enum.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Let's go back with the definition of the Protocol.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In addition to specifying requirements that conforming types must implement, you can extend a protocol to implement some of these requirements or to implement additional functionality that conforming types can take advantage of.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote></blockquote><div><br></div><div><div class="gmail_default" style="display:inline">So if there are some independent protocols accidentally sharing the same vars or functions, this does not violate the definition of the protocol. Should the compiler warns the programmer? Maybe, as we can not sure there must be conflicts. So I think the alert level is between warning and silence. </div></div><div><div class="gmail_default" style="display:inline"><br></div></div><div><div class="gmail_default" style="display:inline">Let's also see the solutions. The solutions in other languages inspire us what to do. One is to change the properties names, the other is to cast the type to the protocol. </div></div><div><div class="gmail_default" style="display:inline"><br></div></div><div><div class="gmail_default" style="display:inline">I think the prior method is much easier to go with. As currently, you can't name a store properties in extension, and you can't have two properties with the same name in extension. However, there is also a problem after you rename the property. As it is no longer the name that defined in the protocol, you can use it with (self as Protocol).name. So maybe we can use lable to solve the problem.</div></div><div><div class="gmail_default" style="display:inline"><br></div></div><div><div class="gmail_default" style="display:inline"><span style="font-size:13px">Basically:</span></div></div><div><div class="gmail_default" style="display:inline"><font style="font-size:13px" face="arial, helvetica, sans-serif"> type A: Marriageable, CallReceivable {<br></font><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote></blockquote><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><font face="arial, helvetica, sans-serif"> var Marriageable.ring ring: String? { ... }<br> var CallReceivable.ring ringtone: String? { ... }<br>}</font><br><br></blockquote><span style="font-size:13px;font-family:arial,helvetica,sans-serif">to call it </span><span style="font-size:13px;font-family:arial,helvetica,sans-serif">:</span><br style="font-size:13px"><blockquote style="font-size:13px;margin:0px 0px 0px 40px;border:none;padding:0px"><font face="monospace, monospace">(self as Marriageable).ring or self.ring<br></font><span style="font-family:monospace,monospace">(self as </span><span style="font-family:monospace,monospace">CallReceivable</span><span style="font-family:monospace,monospace">).ring or self.ringtone</span></blockquote></div></div><div><div class="gmail_default" style="display:inline"><br></div></div><div><div class="gmail_default" style="display:inline">zhaoxin</div></div><div> </div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Jan 11, 2016 at 8:17 AM, Wallacy via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I Like this C#'s "Explicit Interface Implementation".<div>The cast to call is understandable, it's good, but just think about. If we use "self.Marriageable.ring" or "variable.Marriageable.ring" will make more symmetrical with the implementation? "dot protocol" can be used to all "explicit call", ambiguous or not.</div></div><br><div class="gmail_quote"><div><div><div dir="ltr">Em dom, 10 de jan de 2016 às 21:49, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> escreveu:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Sorry if this is already mentioned, but I quite like C#'s "Explicit Interface Implementation" approach:<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><a href="https://msdn.microsoft.com/en-us/library/ms173157.aspx" target="_blank">https://msdn.microsoft.com/en-us/library/ms173157.aspx</a></div></blockquote><br>Basically:<font face="monospace, monospace"><br></font><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span style="font-family:monospace,monospace">var Marriageable.ring: String? { ... }</span><br><font face="monospace, monospace">var CallReceivable.ring: String? { ... }<br><br></font></blockquote><span style="font-family:arial,helvetica,sans-serif">to call it you could do </span><font face="monospace, monospace">self.ring</font><span style="font-family:arial,helvetica,sans-serif"> if it was unambiguous, otherwise:</span><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><font face="monospace, monospace"> (self as Marriageable).ring<br></font><span style="font-family:monospace,monospace">(self as </span><span style="font-family:monospace,monospace">CallReceivable</span><span style="font-family:monospace,monospace">).ring</span><font face="monospace, monospace"><br></font></blockquote><font face="monospace, monospace"><br></font></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 11, 2016 at 9:51 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> By giving warning simply for same name, it will be quite annoying when the project run into this situation without any wrong. For example:<br>
><br>
> protocol ForwardIndexType : _Incrementable {<br>
> @warn_unused_result<br>
> public func advancedBy(n: Self.Distance) -> Self<br>
> }<br>
><br>
> extension ForwardIndexType {<br>
> @warn_unused_result<br>
> public func advancedBy(n: Self.Distance) -> Self<br>
> @warn_unused_result<br>
> public func advancedBy(n: Self.Distance, limit: Self) -> Self<br>
> @warn_unused_result<br>
> public func distanceTo(end: Self) -> Self.Distance<br>
> }<br>
><br>
> protocol BidirectionalIndexType : ForwardIndexType<br>
> extension BidirectionalIndexType {<br>
> @warn_unused_result<br>
> public func advancedBy(n: Self.Distance) -> Self<br>
> @warn_unused_result<br>
> public func advancedBy(n: Self.Distance, limit: Self) -> Self<br>
> }<br>
<br>
</span>Firstly, for methods and subscriptors the "name" would actually encompass the entire signature, so `advancedBy(_:)` and `advancedBy(_:limit:)` would not conflict because they have different signatures.<br>
<br>
Secondly, `ForwardIndexType` and `BidirectionalIndexType` are *not* unrelated protocols—one of them conforms to the other. Thus, we can assume that `BidirectionalIndexType` knows about `ForwardIndexType`'s `advancedBy` methods and intends for its versions to have compatible semantics.<br>
<br>
If instead `BidirectionalIndexType` did *not* conform to `ForwardIndexType`, and `RandomAccessIndexType` tried to conform to both `ForwardIndexType` and `BidirectionalIndexType`, *then* we would get an error, because two independent protocols would have declared `advancedBy(_: Self.Distance) -> Self` methods and it's possible they meant for them to have different semantics.<br>
</blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br></div></div></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div></div>
</div></div><img alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<span><br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></blockquote></div>
<img alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><br>Owen Zhao<br></div></div></div>
</font></span></div>
</blockquote></div><br></div>