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

[Matthew Johnson]

> On Dec 20, 2015, at 1:06 AM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Interesting proposal, but how would it work with closures that take two
> or more params? What would the following expression become:
> 
> [1,2,3,4].reduce("", { $0.description + $1.description })
> 
> Is this special syntax that would only apply to closures with one
> parameter? If so I'm not sure that I would consider it worth the added
> complexity (though I agree that the $0 doesn't look that nice normally).

It wouldn’t work for two or more arguments.  The point of it is to be shorthand for unbound instance members (or partially bound if we allow methods taking additional arguments), which would inherently receive a single argument - the instance.

Whether or not it is worth the cost is a fair question that needs to be answered through discussion.

I think it is worth continuing to discuss and explore because it addresses a very common use case.  Many higher order functions take function arguments that receive only a single argument.

> 
> - Kevin
> 
> On 12/17/2015 10:27 PM, Matthew Johnson via swift-evolution 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution