[swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines

[Dave Abrahams]

on Fri Jan 22 2016, David Owens II <swift-evolution at swift.org> wrote:

>> On Jan 22, 2016, at 4:12 PM, Ross O'Brien <narrativium at gmail.com> wrote:
>> 
>> How would we apply this to delegate patterns?
>> For example, would we keep
>> tableview(tableView:cellForRowAtIndexPath:), or would we switch to
>> delegate(tableView:cellForRowAtIndexPath:) ?
>> Or perhaps better, for clarity over which protocol is being
>> conformed to / which property of the delegator is calling the
>> function:
>> dataSource(tableView:cellForRowAtIndexPath:),
>> delegate(tableView:didSelectRowAtIndexPath:)
>
> There would be no argument label for `tableView`; it’s a needless word
> and there is a strong type information: it’s a TableView.
>
> Weak type information would be like “key path” below. Yes, it’s
> String, but it’s actually a specially crafted string that takes the
> form: “some.nested.values”. A string like “some+234+//23” is not going
> to work.
>
> I’m also not really convinced that `removeAt(position: Int)` doesn’t
> actually fall under both rules. The first parameter is a weak type; it
> has rules associated with it (non-zero and less than collection
> size). In the guidelines, it could be argued that it should be
> `removeAtIndex(position: Int)`. I’d prefer the `removeAt(index
> position: Int)` version. But, you can kinda make the weak type
> argument for a lot of scenarios… It’s a little ambiguous to me.

Point taken.  We don't include “Index” becase removeAt with an Int
argument is just one realization of a protocol requirement where the
argument is an Index.  We could have said, “add type information to
compensate for the *possibility* of weak type information whenever you
are using a protocol's associated type, because in some cases the
concrete type may have other roles.”  However, the litmus test being
“what leads to better code at the use-site?”, I don't think we want to
do that, because its overall effect would be worse.

IMO-ly y'rs,

-- 
-Dave