<div dir="ltr">If the use case is to support certain protocol requirements rather than avoiding the recitation of long names, then it doesn't have to be short. IMO, `Type` is problematic because there's nothing in the meaning of the word to distinguish from `Self`, and in any case it's already used for the metatype type. `StaticSelf` is unambiguous.<div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 5:32 PM, Matthew Johnson 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="auto"><div><br><br>Sent from my iPad</div><span class=""><div><br>On May 10, 2016, at 5:24 PM, Hooman Mehr <<a href="mailto:hooman@mac.com" target="_blank">hooman@mac.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div>That said, I’m not sure I understand the concrete use-cases. When is this concept important? When is “Self” not good enough?</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">The only case where there is new functionality is when this is used in a protocol requirement. I gave an example earlier today. </div></div></blockquote></div><br><div>This functionality is the key: Ability of an open (non-final) class to conform to a protocol that lets it return an instance of the conforming type (itself). Self does not work for that and we can’t change its behavior (or can we?) So one solution seems to be Matt’s proposal. This functionality is important for me and an example use case is class clusters. For the client code it is sealed and acts just like a final class, but internally it may return a subclass that is an implementation detail. We should be able to do this.</div></div></blockquote><div><br></div></span>Agree and this is why I am willing to write the proposal for this. There was a discussion a few months ago about this problem and a few solutions were kicked around. The biggest problem with this approach at the time was lack of a good name, which I believe we now have in Type.<div><br></div><div>I'm going to let the discussion continue for a day or two and will write a proposal if no significant counter arguments arise.</div><div><br></div><div>-Matthew<br><div><br><blockquote type="cite"><div><div><br></div><div>Hooman</div></div></blockquote></div></div></div><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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div></div>