[swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels
Vladimir.S
svabox at gmail.com
Mon Jul 4 06:36:21 CDT 2016
On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote:
>> * What is your evaluation of the proposal?
>
> I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type.
>
> In the long run, it must be possible to label the parameters of a closure. But that labeling does not *necessarily* belong on the type; it could go on the name:
>
> // Old and busted
> let completion: (records: [Record]?, error: Error?) -> Void
> // New hotness
> let completion(records:error:): ([Record]?, Error?) -> Void
>
I really like this idea. Clearly separated "name" and "type" of the
function/closure just like for like for any other "simple" variable like
`let value: Int`
The only note : I believe we should be still allowed to define func
variable without labels, if I don't care about them.
let completion: ([Record]?, Error?) -> Void
> And I don't think it would be terrible to remove the labels from the type before we add them to the name.
>
Support. But it will be great if we'll have both at the same time.
> On the other hand, we could go the other direction and make the labels significant. Or—to address the `remove(from:)`/`add(to:)` critique—we could perhaps make the *internal* names significant, while considering the internal labels as part of the variable name. (Presumably both `remove(from:)` and `add(to:)` would be of type `(collection: WidgetCollection) -> Void`.)
I don't feel like this is correct direction. For me parameter labels
definitely belongs to name of func variable, not to type.
>
> Both options are sensible; the status quo is not. We should choose a direction and start going that way.
>
>> * Is the problem being addressed significant enough to warrant a change to Swift?
>
> Yes. The type system is being a bit nonsensical here.
>
>> * Does this proposal fit well with the feel and direction of Swift?
>
> Yes. Swift 3, breaking everything now, etc.
>
>> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>
> Can't really think of much that's comparable.
>
>> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> Quick reading.
>
More information about the swift-evolution
mailing list