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

[Johan Jensen]

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 <
swift-evolution at swift.org> wrote:

>
> On Dec 18, 2015, at 6:52 AM, Al Skipp <al_skipp at fastmail.fm> wrote:
>
> On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution <
> 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
>
>
> 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
> swift-evolution at swift.org
> 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/4b02b7f8/attachment.html>