Sent from my iPad
> On May 10, 2016, at 4:01 PM, Chris Lattner <clatt...@apple.com> wrote: > > On May 10, 2016, at 12:03 PM, Matthew Johnson <matt...@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
