[swift-evolution] [RFC] #Self

Matthew Johnson matthew at anandabits.com
Tue May 10 16:49:15 CDT 2016



Sent from my iPad

> On May 10, 2016, at 4:01 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On May 10, 2016, at 12:03 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>>> 
>>>> That's a fair critique.  Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
>>>> 
>>>> How about #Type or #StaticType?
>>> 
>>> Either of those would make more sense to me than using # as a distinguisher for dynamic vs static.  This isn’t what we use # for.
>> 
>> Another suggestion was StaticSelf.  Any opinion on that one?  Also, do you think we should just drop the # altogether?
>> 
>> If we find a name we can agree on and there is no significant opposition is this a proposal that could make it into Swift 3?  I would be willing to write one if that is the case.
> 
> I haven’t thought about this in depth and completely misunderstood the proposal before :-)
> 
> If I understand, this is simply a shortcut to avoid having to spell out the static type name, most useful when copying/pasting code or when the type name is long.  That argues for keeping it short (a knock against StaticSelf).  Also, I think it would make sense to drop the #: Self doesn’t have it for example, and that is the closest relative.

Good point about keeping it short.  'Type' seems like the best candidate.

> 
> That said, I’m not sure I understand the concrete use-cases.  When is this concept important?  When is “Self” not good enough?

The only case where there is new functionality is when this is used in a protocol requirement.  I gave an example earlier today.  

It also provides a shortcut for verbose type names, although that is relatively unimportant.

> 
> -Chris
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/ea3cce59/attachment.html>


More information about the swift-evolution mailing list