> On Dec 18, 2015, at 1:36 PM, Radosław Pietruszewski <[email protected]> wrote: > > Interesting! I’d definitely be for some shortcut syntax here, as this seems > to be a very, very common pattern. Passing a function to, say, `map` is so > much easier and cleaner than passing a method in Swift — even though Swift > generally always prefers methods to functions! > > I haven’t spent too much thinking this through, but I think this is sound. > > For contexts where a T is expected, .foo means T.foo > > But it’s not ambiguous here, because we’re expecting T -> U here, and > functions can’t have static members (or any members for that matter :P). So > passing a .foo could unambiguously mean T.foo(T) — an instance method on T, > returning U. > > I’d be for dropping the parens, they seem unnecessary, and are confusing > (we’re passing a function, not calling it). It should be unambiguous with > properties since methods and properties share a name space. > > And, speaking of, I’d also just make it work with properties with the same > syntax. So array.map(.foo) would call $0.foo() if `foo` is a method, or > $0.foo if `foo` is a property.
I probably should have showed more examples in my original post. Making this work with property getters was one of the examples I posted in the other thread: anArray.map(.aProperty) The reason I used parentheses in the example of a method that takes no argument is that what we’re actually doing is binding the non-self arguments. This is more clear with an example of a method that does take additional arguments: anArray.map(.hasPrefix(“foo”)) I hadn’t tried declaring property and no argument method with the same name until you said this. You are correct that it’s unambiguous. I didn’t realize this when I first posted this idea. If we don’t omit them it’s always clear whether we are passing a property or a method. I think requiring the parentheses is probably worth the syntactic cost. It also allows for a straightforward rewrite to a closure by wrapping the expression in braces and placing $0 prior to the dot. > > (Am I missing something?) > > — Radek > >> On 18 Dec 2015, at 04: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 >> _______________________________________________ >> 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
