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] <mailto:[email protected]>> wrote:
>
>> On Dec 18, 2015, at 6:52 AM, Al Skipp <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution
>>> <[email protected] <mailto:[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] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
