> +1. One important consideration, however, and I would love to see some input > from Chris Lattner or someone else who works on LLVM, is how much it would > complicate the grammar of the language when all possible cases are considered.
I ran this by Joe Groff on Twitter and he said it makes sense. Would be great to get a comment on the list as well. It’s quite similar to the existing dot shorthand for static members but applies in a different typing context. I may be overlooking something but I don’t believe there would be any complications that were not addressed there. > > On Fri, Dec 18, 2015, 8:05 AM Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Dec 18, 2015, at 6:52 AM, Al Skipp <al_sk...@fastmail.fm >> <mailto:al_sk...@fastmail.fm>> wrote: >> >>> On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
