[swift-evolution] [Proposal Idea] dot shorthand for instance members

Sean Kosanovich sean7512 at me.com
Fri Dec 18 08:46:36 CST 2015


Matthew,

Understood, I just wanted to link the conversations together.

As for the idea, I am a huge fan of removing the necessary $0.

-Sean

> On Dec 18, 2015, at 7:57 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> Thanks for lining to the original thread Sean.  I should have done that myself.
> 
> I started a new thread as this is really an independent feature that is related to the spread operator but stands on its own.  It deserves a thread and subject line of its own.
> 
> Matthew
> 
> 
> Sent from my iPad
> 
> On Dec 18, 2015, at 6:38 AM, Sean Kosanovich <sean7512 at me.com <mailto:sean7512 at me.com>> wrote:
> 
>> This was/is being discussed at length in this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002742.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002742.html>
>> 
>> 
>> 
>>> On Dec 17, 2015, at 10:27 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Swift currently offers dot shorthand for static members of type Self in type contexts expecting a value of the type in question.  This is most commonly used with enum cases.
>>> 
>>> Swift does not currently offer shorthand for instance members.  Introducing a shorthand for instance members would improve clarity and readability of code in common cases:
>>> 
>>> anArray.map{$0.anInstanceMethod()}
>>> 
>>> becomes:
>>> 
>>> anArray.map(.anInstanceMethod())
>>> 
>>> This shorthand would work in typing contexts expecting a single argument function.  It would allow abbreviated access to any visible instance property getter or instance method on the type of the argument.  Of course the return type would need to match the return type expected by the context or a type mismatch compiler error would occur.
>>> 
>>> The readability advantage is arguably small but it does exist.  The feature also aligns very well with an existing language feature.
>>> 
>>> I think it’s an interesting idea and am wondering whether others feel like it is something worth pursuing or not.
>>> 
>>> Matthew
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/629170dc/attachment.html>


More information about the swift-evolution mailing list