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

Michael Wells michael at michaelwells.com
Fri Jan 22 18:26:42 CST 2016


> On Sat, Jan 23, 2016 at 12:00 AM, David Owens II via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Compensate For Weak Type Information as needed to clarify a parameter’s role.
>> 
>> Especially when a parameter type is NSObject, Any, AnyObject, or a fundamental type such Int or String, type information and context at the point of use may not fully convey intent. In this example, the declaration may be clear, but the use site is vague:
>> 
>> func add(observer: NSObject, for keyPath: String)
>> grid.add(self, for: graphics) // vague
>> 
>> To restore clarity, precede each weakly-typed parameter with a noun describing its role:
>> 
>> func addObserver(_ observer: NSObject, forKeyPath path: String)
>> grid.addObserver(self, forKeyPath: graphics) // clear
> 

Where this rule feels clumsy to me is in code such as

func loginWithUsername(username: String, password: String) -> Bool

vs.

func login(username: String, password: String) -> Bool

But maybe it just takes some time to get used to the style.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160122/dc202a54/attachment.html>


More information about the swift-evolution mailing list