[swift-evolution] Spread Operator as Shorthand for Map
matthew at anandabits.com
Wed Dec 16 10:34:07 CST 2015
This wouldn’t be ambiguous with static methods. Confusing to some developers possibly, but not ambiguous. Map would be expecting a function that takes an instance. Depending on the details of how it was defined in the language it could be ambiguous with a static property of a function type:
static let make: Car -> SomeOtherType
This potential ambiguity could probably be defined away by making the shorthand specifically apply to instance methods or something like that.
There would not be an entirely new meaning for the . shorthand. It would be an extrapolation of the shorthand for enum cases.
That said, I was replying quickly and my example was not quite accurate. “make" is a getter which cannot be accessed in unbound form today. There are proposals to allow this to be done in other threads. Syntax from one example is Car.make#get (lets not get caught up on syntax of that here). So correcting my example it would look like:
If make was a method we would need to bind all of the arguments except the curried instance argument so it would look like this:
And a method with more arguments would look like this:
cars.map(.methodWithInt(1, string: “hello"))
I’m not necessarily advocating for something like this, just trying to think through the implications of it at this point.
> On Dec 16, 2015, at 10:18 AM, Stephen Celis <stephen.celis at gmail.com> wrote:
> On Wed, Dec 16, 2015 at 10:50 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> If we peel off just the contextual shorthand aspect of this proposal you could write:
> That does seem like a big win if it is feasible (doesn’t introduce ambiguity or cause other significant challenges in implementation).
> The above creates ambiguity if there were a `map` function that takes a type with a static member `make`.
> Both create an additional meaning for dot abbreviation, though, which is confusing. I think I'm "-1" on this proposal as is. The existing form is clearer and relatively short as is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution