> On 27 Jun 2016, at 11:00, Manuel Krebber via swift-evolution 
> <[email protected]> wrote:
> 
> Hi everyone,
> 
> I was thinking it would be nice to have a similar short notation for
> using methods in a functional way as there is for enum cases (and as
> I've been told static members in general).
> Let me give a rather contrived example:
> 
> struct Foo {
>    let bar: Int
> 
>    func getBar() -> Int {
>        return self.bar
>    }
> 
> }
> 
> let foos = [Foo(bar: 1), Foo(bar: 2), Foo(bar: 3)]
> let bars = foos.map{ $0.getBar() }
> 
> What I am suggesting is to add syntactic sugar to bridge the gap between
> functional and object oriented programming. So instead you could write
> the following:
> 
> let bars = foos.map(.getBar)

While I see some potential in this, I wonder if it's a bit too ambiguous at the 
moment, and might require a wider rethink of the dot shorthand; in the example 
above it's not clear at a glance that this references the .getBar method of 
elements, vs a property or method of foos, or self, or Self. Enums are kind of 
a special case, but they are at least a static member so there's a clearer case 
for them vs this example which is an instance member, which could lead to 
ambiguity.

I mean, I'd be all for allowing this shorthand for instance members as well, 
but we'd need to get around issues of this ambiguity, perhaps with a shorthand 
identifier for type? As pointed out, you can actually use Foo.getBar, but while 
this is fine for a type with such a short name, it's not convenient if your 
type name is much longer, meaning in many cases it will remain easiest to just 
do { $0.getBar() } or similar. If we could reserve a special type identifier, 
or use $T or something it might be easier, but it'd need to be an elegant 
choice (I don't really like either of mine, it's just to give the idea).
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to