[swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels
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