For me there are two sources to the feeling of noise with simple
single-statement closures and using $0, etc. - The first are the braces that
seem redundant when there’s only a single statement, and the second is the
presence of $0.
I played around a bit, and this is probably just a personal preference thing,
but I don’t think it’s the $ that bothers me, really, but instead it is the
digit that makes it feel noisy. When I change $0 to $a, $b, etc. suddenly the
code doesn’t feel so noisy to me. This may simply be because I rarely ever put
a number in my variable names, and if I do, I almost always start at 1 and not
0. :P Again, this might just be me. :)
someArray.map({ $0.property })
someArray.map({ $a.property })
Then it occurred to me that for the simple case of doing a map or filter or
whatever using a single method call, what if Swift could instead make an
assumption that if there’s a $ variable outside of a closure, we meant to start
a single-statement closure so something like this could be possible:
someArray.map($0.property)
someArray.map($a.property)
And going farther with this, in the case where there’s only a single argument
in the closure, maybe we could skip the number/letter entirely and just use are
bare $ instead of $0:
someArray.map({ $.property })
And finally, combined with the single-statement shortcut:
someArray.map($.property)
l8r
Sean
> On Dec 18, 2015, at 9:31 AM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
> Johan, you are right that all of this is possible but it seems rather verbose
> to me. I’d rather use the currently possible { $0.member } syntax. The
> point of the idea is to remove syntactic noise.
>
> It’s reasonable to argue that this isn’t necessary, but in that case the
> current state suffices IMO. We don’t need a more verbose alternative to what
> we already have.
>
>
>> On Dec 18, 2015, at 9:00 AM, Johan Jensen <[email protected]> wrote:
>>
>> I’m not very fond of having just a single dot in front of the method call,
>> as it could easily be missed.
>> In the case of s.predicate = .hasPrefix("abc"), I would prefer something
>> slightly more expressive.
>>
>> As it is right now in Swift, accessing methods directly gives you a curried
>> function back, which expects the object instance as argument in the first
>> call, and the rest in the second call.
>> E.g. String.hasPrefix("abcd")("a") is the same as "abcd".hasPrefix("a")
>>
>> Flipping the arguments like this:
>> func flip<A, B, C>(f: A -> B -> C) -> (B -> A -> C) {
>> return { valB in
>> return { valA in
>> return f(valA)(valB)
>> }
>> }
>> }
>>
>> String.hasPrefix("abcd")("a")
>> let myHasPrefix = flip(String.hasPrefix)
>> myHasPrefix("a")("abcd")
>>
>> …would allow us to write the following:
>> s.predicate = flip(String.hasPrefix("abcd"))
>>
>> Perhaps it could be extended to something akin to
>> s.predicate = String::hasPrefix("abcd")
>>
>> The currying only works for methods and not for properties, so this isn’t
>> currently possible to express like the above:
>> ["John", "Rachel", "Thomas"].map({ $0.endIndex })
>> ["John", "Rachel", "Thomas"].map({ $0.characters.count })
>>
>> —Johan
>>
>> On Fri, Dec 18, 2015 at 2:05 PM, Matthew Johnson via swift-evolution
>> <[email protected]> wrote:
>>
>>> On Dec 18, 2015, at 6:52 AM, Al Skipp <[email protected]> wrote:
>>>
>>>> On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution
>>>> <[email protected]> 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
>>>
>>> I’d be interested to hear peoples thoughts regarding this proposal. I’m
>>> personally in favour, but perhaps there are potential issues with the
>>> suggestion?
>>>
>>> It’s only a small visual change, but I think it is a syntactic improvement.
>>> Let’s pretend for a moment that the current syntax was:
>>> anArray.map(.anInstanceMethod())
>>>
>>> I’m not sure many people would argue for it to be changed to:
>>> anArray.map { $0.anInstanceMethod() }
>>
>> Thanks Al. I should have also pointed out that the syntactic advantage is a
>> bit greater in other contexts where the braces would not replace parentheses:
>>
>> struct S {
>> var predicate: String -> Bool
>> }
>>
>> var s = S()
>> s.predicate = { $0.hasPrefix(“abc”) }
>>
>> vs
>> s.predicate = .hasPrefix(“abc”)
>>
>> It’s not a super important change, but maybe a low-hanging fruit item that
>> can improve clarity and readability.
>>
>> 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
