They can always add the new mapping, and leave the old one there but deprecate
> On Oct 18, 2016, at 8:51 PM, Hooman Mehr via swift-evolution
> <email@example.com> wrote:
> Is changing the mapping of Cocoa API considered a source breaking change or
> can we report such incidents as bugs if we think they don’t match API
>> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution
>> <firstname.lastname@example.org <mailto:email@example.com>> wrote:
>> on Tue Oct 18 2016, Brandon Knope <firstname.lastname@example.org
>> <mailto:email@example.com>> wrote:
>>> I meant to bring this up a bit ago but just came across it again.
>>> I find this to not read properly:
>>> button.setTitle("Test", for: .normal) //for normal what?
>>> The for argument is really only clear in meaning when you are typing
>>> it out and see that it is a UIControlState type. While reading it
>>> without this context is it as clear? .normal doesn't seem descriptive
>>> enough on its own.
>>> Contrast this with UISegmentedControl:
>>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState:
>>> .normal, barMetrics:
>>> Here the parameter labels are needed because there needs to be a
>>> distinction in the method between left and right. But here it is not
>>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>>> So my question is: why was this not setTitle(forControlState:) or
>>> forButtonState, etc...?
>> This is really not an evolution question at this point. I suggest
>> filing radars against UIKit for things whose names could be improved.
>> swift-evolution mailing list
>> firstname.lastname@example.org <mailto:email@example.com>
> swift-evolution mailing list
swift-evolution mailing list