[swift-evolution] Spread Operator as Shorthand for Map

Árpád Goretity arpad.goretity at gmail.com
Mon Dec 28 11:53:01 CST 2015


Seems sensible; here's my $0.02:

I don't know whether that kind of thing has been proposed, but it would be interesting to explore two different language features and their interaction with first-class getters and setters. This way, I believe, we could avoid introducing non-orthogonality and special cases into the language.

The first feature is uniform function call syntax:
 - for structs and final classes (where there's no inheritance), if a function is declared with the struct type as its first parameter, e.g. some_property(self: MyStruct) {…}, it could be called as if it was a method on the struct (cf. Go's behavior). With this behavior would be consistent the ability to simply map getters and setters over a collection of structs (or otherwise treat technically free functions as methods if the types match).
 - for non-final classes, inheritance kicks in. In this case, I think it's a little too magical (albeit certainly not hard to implement) to have one function name map to several functions (i.e. have inheritance semantics), especially without visual indication of the object being manipulated. There's a source of mental tension here, though: specifically, this behavior would however be consistent with the notion of overridden functions at the same time.

The second feature is macros - I know that they have been discussed and postponed for now, but theoretically they'd be capable of solving the kinds of syntactic repetition that can't otherwise be refactored into functions. The standard library could then contain macros which would expand to appropriate getters and setters - pseudocode follows:

    macro get(name: Identifier) {
        return { $0.`name` }
    }

    macro set(name: Identifier) {
        return { $0.`name` = $1 }
    }

What do you think about this?

Sent from my iPhone

> On 28 Dec 2015, at 18:10, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1 for being able to use cars.map(make)
> 
>> Am 16.12.2015 um 16:23 schrieb Al Skipp via swift-evolution <swift-evolution at swift.org>:
>> 
>>> On 16 Dec 2015, at 12:47, Sean Kosanovich via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> As a Groovy user, I really enjoy the shorthand Spread Operator over the Collect Closure (Map is the equivalent in Swift).
>>> 
>>> Consider the following Swift code:
>>> 
>>> struct Car {
>>>     let make: String
>>>     let model: String
>>> }
>>> 
>>> let cars = [Car(make: "Jeep", model: "Grand Cherokee"), Car(make: "Dodge", model: "Challenger")]
>>> let makes = cars.map() { $0.make }
>>> 
>>>  
>>> 
>>> Now consider the same code using a Spread Operator:
>>> 
>>> let makes = cars*.make
>> 
>> I think there is a tension in Swift between its object oriented nature and higher-order functions which leads to a lot of repetition of { $0.property }
>> 
>> In this example:
>> cars.map { $0.make }
>> 
>> I’d like to write the following, but ‘make’ is a member, not a free function:
>> cars.map(make)
>> 
>> Is anyone else irked by the preponderance of { $0.property } in Swift (or is it just me being grumpy)? Not sure what the solution would be, but I can’t say I’m keen on the suggestion of:
>> 
>> cars*.make
>> 
>> It’s too mysterious.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20151228/d67c236c/attachment.html>


More information about the swift-evolution mailing list