> On Dec 20, 2015, at 1:06 AM, Kevin Lundberg via swift-evolution
> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
