<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">After taking the time to look at a few more delegate-style protocols it’s a lot less obvious that the existing delegate-style protocols would, in general, support such a transform (or at least an automated one).</div><div class=""><br class=""></div><div class="">The `UIPageViewDataSource` API is a good short example:</div><div class=""><br class=""></div><div class="">// original:</div><div class="">func pageViewController(pageViewController: UIPageViewController, viewControllerAfterViewController viewController: UIViewController) -> UIViewController?</div><div class=""><div class="">func pageViewController(pageViewController: UIPageViewController, viewControllerBeforeViewController viewController: UIViewController) -> UIViewController?</div></div><div class=""><br class=""></div><div class="">// best-plausible automated output (IMHO):</div><div class="">func viewControllerAfter(pageViewController: UIPageViewController, viewController: UIViewController) -> UIViewController? </div><div class="">func viewControllerBefore(pageViewController: UIPageViewController, viewController: UIViewController) -> UIViewController? </div><div class=""><br class=""></div><div class="">// manual-option A:</div><div class="">func viewController(in pageViewController: UIPageViewController, after viewController: UIViewController) -> UIViewController? </div><div class=""><div class="">func viewController(in pageViewController: UIPageViewController, before viewController: UIViewController) -> UIViewController? </div></div><div class=""><br class=""></div><div class=""><div class="">// manual-option B:</div></div><div class=""><div class="">func nextViewController(in pageViewController: UIPageViewController, after viewController: UIViewController) -> UIViewController? </div><div class="">func previousViewController(in pageViewController: UIPageViewController, before viewController: UIViewController) -> UIViewController? </div></div><div class=""><br class=""></div><div class=""><div class="">…wherein in case it’s not clear, the problem is that the general rule of “take the first non-delegate argument, split off the explanatory part, and use it as a method” leads to a more-confusingly-named function; this can obviously be corrected manually, but I’m skeptical the automated approach can be extended to cover such scenarios without requiring a lot of manual intervention/annotation.</div><div class=""><br class=""></div><div class=""><div class="">Additionally, there are related cases like `NSKeyedUnarchiverDelegate`, which have the similar issue of being arguably worse-off for the transformation under most plausible edits in that style; consider e.g.:</div></div><div class=""><br class=""></div><div class="">// original</div><div class=""><div class="">func unarchiver(unarchiver: NSKeyedUnarchiver, didDecodeObject object: AnyObject?) -> AnyObject? // lets you replace `object` with something else</div><div class="">func unarchiver(unarchiver: NSKeyedUnarchiver, willReplaceObject object: AnyObject, withObject newObject: AnyObject) <br class="">func unarchiver(unarchiver: NSKeyedUnarchiver, cannotDecodeObjectOfClassName name: String, originalClasses classNames: [String]) -> AnyClass? // lets you suggest an alternative class to try<br class=""></div></div><div class=""><br class=""></div><div class="">// plausible mechanical transforms</div><div class="">func didDecode(unarchiver: NSKeyedUnarchiver, object: AnyObject?) -> AnyObject? </div><div class="">func didDecodeObject(unarchiver: NSKeyedUnarchiver, object: AnyObject?) -> AnyObject? </div><div class="">func didDecode(unarchiver: NSKeyedUnarchiver, decodedObject: AnyObject?) -> AnyObject? </div><div class=""><br class=""></div><div class="">func willReplace(unarchiver: NSKeyedUnarchiver, object: AnyObject?, withObject newObject: AnyObject)</div><div class="">func willReplaceObject(unarchiver: NSKeyedUnarchiver, object: AnyObject?, withObject newObject: AnyObject)</div><div class=""><br class=""></div><div class="">func cannotDecodeObject(unarchiver: NSKeyedUnarchiver, className name: String, originalClasses classNames: [String]) -> AnyClass?</div><div class="">func cannotDecodeObjectOfClass(unarchiver: NSKeyedUnarchiver, name: String, originalClasses classNames: [String]) -> AnyClass?</div><div class=""><div class="">func cannotDecodeObjectOfClass(unarchiver: NSKeyedUnarchiver, className: String, originalClasses classNames: [String]) -> AnyClass?</div></div><div class=""><br class=""></div><div class="">…none of which are really any clearer, to my eyes (and still rather far from the semantics, as the `didDecode` is really asking if you want a replacement object, and the `cannotDecode…` is really asking for another class to try given that unarchiving using the archive-specified class has failed).</div><div class=""><br class=""></div><div class="">Finally, there are also APIs like `NSURLSessionDataDelegate` which have *2* “delegate-style” parameters: `URLSession(_:dataTask:didReceiveResponse:completionHandler:` (and possibly others), so an automated transform has to somehow handle such cases.</div><div class=""><br class=""></div><div class="">Given all of these, perhaps the best that can be done at this time is to try and get the general guidelines such that for *new* delegate APIs it’ll be possible to give them Swift names that are guideline-conformant, but can still be exposed to Objective-C (where necessary) in an idiomatic way (e.g., has the arguments in the right ordering to be a delegate/datasource/etc. call in Objective-C).</div><div class=""><br class=""></div><div class="">But at least at this point I’m rather dubious there’s a worthwhile transformation out there that can be uniformly applied to the “SDK delegate/datasource protocols” and lead to an overall improvement.</div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class="">On Jan 30, 2016, at 12:06 PM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 26, 2016, at 6:34 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">on Tue Jan 26 2016, plx <</span><a href="mailto:swift-evolution@swift.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">swift-evolution@swift.org</a><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">> wrote:</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="">On Jan 24, 2016, at 5:57 PM, Dave Abrahams via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Sat Jan 23 2016, plx <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jan 23, 2016, at 2:33 PM, Dave Abrahams via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Sat Jan 23 2016, plx<br class=""></blockquote><br class=""><blockquote type="cite" class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jan 22, 2016, at 6:12 PM, Ross O'Brien via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">How would we apply this to delegate patterns?<br class="">For example, would we keep<br class="">tableview(tableView:cellForRowAtIndexPath:), or would we switch to<br class="">delegate(tableView:cellForRowAtIndexPath:) ?<br class="">Or perhaps better, for clarity over which protocol is being<br class="">conformed to / which property of the delegator is calling the<br class="">function:<br class="">dataSource(tableView:cellForRowAtIndexPath:),<br class="">delegate(tableView:didSelectRowAtIndexPath:)<br class=""></blockquote><br class="">FWIW, I am personally favorable to a more radical-renaming for<br class="">delegate methods, roughly the below:<br class=""><br class="">func numberOfSections(inTableView tableView: UITableView) -> Int<br class="">// <- against guidelines, but symmetric<br class="">func numberOfRows(inTableView tableView: UITableView, forSection section: Int) -> Int<br class="">func cellForRow(inTableView tableView: UITableView, atIndexPath<br class="">indexPath: NSIndexPath) -> UITableView<br class=""></blockquote><br class="">The interesting thing about delegate methods is that, for the most part,<br class="">use-sites don't appear in user code. So *if* you're going to come up with<br class="">special conventions just for delegate methods you'd want to serve the<br class="">declaration site. I don't know what these things *ought* to look like,<br class="">but the declarations above look to me like they've got an awful lot of<br class="">redundancy that doesn't help readability.<br class=""></blockquote><br class="">Most of what follows should really be in the discussion about the<br class="">Objective-C import, not here, but I’ll respond here with the parts<br class="">relevant to the guidelines.<br class=""><br class="">It seems self-evident that imported delegate methods violate the<br class="">spirit of Swift’s API guidelines; in particular, the rule that<br class="">“Methods can share a base name when they share the same basic meaning<br class="">but operate on different types, or are in different domains” seems<br class="">relevant.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">That's quite true.<br class=""><br class=""><blockquote type="cite" class="">It’s thus been a bit surprising to me that delegate-style methods<br class="">haven’t *already* gotten some special treatment;<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">Well, it's a fact of life that major efforts like this one (probably<br class="">property behaviors are the same bucket) are going to have to land<br class="">without solving all the problems they are related to. I believe<br class="">strongly that we should do *something* about delegate methods. I also<br class="">believe they're a separable problem and we should be able to evaluate<br class="">the current direction without working out all the details of how we're<br class="">going to handle them. That's why I changed the subject line: I'd like<br class="">to agree that special treatment for delegate methods in the importer is<br class="">out-of-scope in this review.<br class=""><br class=""><blockquote type="cite" class="">what I had isn’t great, but put it and some variants up against the<br class="">original, like so:<br class=""><br class="">func numberOfRows(in tableView: UITableView, forSection section: Int) -> Int<br class="">func numberOfRowsIn(tableView: UITableView, forSection section: Int) -> Int<br class="">func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int<br class="">func numberOfRows(inTableView tableView: UITableView, forSection section: Int) -> Int<br class=""></blockquote><br class="">I assume you mean the 3rd one to be "the original?”<br class=""></blockquote><br class="">Yes, here: tableView(_:numberOfRowsInSection:)<br class=""><<a href="https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITableViewDataSource_Protocol/#//apple_ref/occ/intfm/UITableViewDataSource/tableView:numberOfRowsInSection:" class="">https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITableViewDataSource_Protocol/#//apple_ref/occ/intfm/UITableViewDataSource/tableView:numberOfRowsInSection:</a>><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">…(note the longest is only ~10 characters longer than the shortest!).<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">Sorry, I don't see why that is relevant. Care to explain?<br class=""></blockquote><br class="">I did not make the intention clear; apologies. I was intending to<br class="">illustrate that although all of the examples contain redundancies,<br class="">none of them are egregiously worse than the others (including the<br class="">original); the worst case is only moderately more-redundant than the<br class="">best case.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I understand that, but if you'll forgive me for being blunt, so what?</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">At the time I thought you meant simply that:</div><div class=""><br class=""></div><div class="">- that the suggestion was annoyingly verbose and redundant</div><div class=""><br class=""></div><div class="">…which seemed an odd criticism, given that “the original” was similarly verbose-and-redundant; however, I think you may have been thinking:</div><div class=""><br class=""></div><div class="">- that because said suggestion was not appreciably-less-redundant than "the original", it’s hard to justify such a transformation (more work for marginal benefit)</div><div class=""><br class=""></div><div class="">…in which case we have may have simply been talking past each other.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><blockquote type="cite" class="">Although there might be an as-yet unseen option that’s superior to all<br class="">of the above, just out of those 4 it’s hard to see how you can justify<br class="">option #3 using the API guidelines;<span class="Apple-converted-space"> </span><br class="">it also seems hard to envision a self-consistent expansion of the<br class="">guidelines that’d lead to favoring #3.<br class=""></blockquote><br class="">You can't.<br class=""><br class=""><blockquote type="cite" class="">As already noted this is really more-relevant to the “objective-c<br class="">import revision”, but you can frame my points as obliquely asking “to<br class="">what extent should the Swift API guidelines actually matter when doing<br class="">the big Objective-C import?”<br class=""></blockquote><br class="">We're willing to accept that some imported APIs will not follow the<br class="">guidelines.<br class=""><br class=""><blockquote type="cite" class="">I also question your sense of real-world use of delegate protocols;<br class="">just taking inventory of the most recent project I completed, it looks<br class="">like it had 5 custom delegate-style protocols. Of these, 4 had exactly<br class="">one implementation each, and 1 had exactly 2 implementations;<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">And how many use-sites were there?<br class=""></blockquote><br class="">5, just counting “classes using said delegates”; 14 if you go by<br class="">individual method use.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">My point is that with most methods, the use sites clearly overwhelm the</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">declaration sites. I don't believe that to be the case with delegates.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">But this is really a minor detail.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">For the “SDK” protocols from Apple this is of course true; on the other hand, most one-off, in-app protocols are declared once, used once, and implemented at-most a couple times (1 being the mode, I’d imagine).</div><div class=""><br class=""></div><div class="">TBH I wouldn’t have noticed the oddity in delegate-style APIs if I hand’t had to create a few one-off ones and noticed how *odd* it is.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">I don’t think this is that untypical. If you accept it as not too<br class="">atypical,<br class=""></blockquote><br class="">I do.<br class=""><br class=""><blockquote type="cite" class="">it suggests a more uniform balance between defining a delegate<br class="">protocol, using said protocol, and implementing said protocol.<br class=""></blockquote><br class="">Not necessarily. How many times did this project implement delegate<br class="">protocols that were defined elsewhere? <br class=""></blockquote><br class="">Looks like 12, for implementations; “a lot”, going by by the method<br class="">count.<br class=""><br class="">In any case I don’t dispute the general point, just perhaps the exit.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">?</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">I meant to type `extent`; apologies.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="">In any case, for what it's worth, I personally think the direction<br class="">you're going with those delegate APIs is great, and it has the benefit<br class="">of bringing them into conformance with other guidelines. My only point<br class="">in saying that the declaration site is more important with delegate<br class="">methods than with others is that there's more type information at the<br class="">declaration site of a method than at its use site, so there's definitely<br class="">no reason to make them more verbose than others. Making them simply<br class="">follow the existing guidelines exactly is a simple solution that IMO<br class="">leads to good code, and one I would support.<br class=""><br class="">However, what Cocoa guys like Tony Parker say about the eventual<br class="">direction of delegate APIs should probably carry a lot more weight than<br class="">what I say.<br class=""><br class=""><blockquote type="cite" class="">To wind this digression down now, the API guidelines’ attitude towards<br class="">redundancy seems somewhat troubling; no one wants needless redundancy,<br class="">but natural languages tend towards redundancy (cf<br class="">agreement/pleonasm/etc) and it’s not at all self-evident that less<br class="">redundancy always implies increased readability (which you may or may<br class="">not be intending to imply; I can’t tell)…especially when it’s easy to<br class="">get fooled by increased speed-of-reading.<br class=""></blockquote><br class="">This seems like a pretty vague concern. Let's see concrete examples of<br class="">problems you think the guidelines' attitude toward redundancy will<br class="">cause. FWIW, "omit needless words" isn't something we just came<br class="">up with ourselves: it's a time-honored principle of clear English<br class="">writing (google it).<br class=""></blockquote><br class="">Sure, sure, but if you’ll forgive a cheap shot I’d point out Strunk<br class="">would’ve tut-tutted here and suggested, perhaps, “we didn’t invent<br class="">‘omit needless words’”. The tricky part of that rule is that what’s<br class="">needless is highly contextual, and to be *understood* when writing in<br class="">a highly-condensed style usually requires a large amount of shared<br class="">context.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Oh, that *was* cheap; and I'm not sure I can forgive it! :-)</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">I only felt justified taking it b/c “came up with ourselves” is at least a borderline pleonasm.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Which need-for-context is at the root of my admittedly-vague concern;<br class="">I’ve done my best to come up with a concrete-ish example, but it’s a<br class="">bit contrived and not as strong as I’d like, either. It’s more of an<br class="">"ecosystem concern”, too.<br class=""><br class="">Here are *six* functions that could conceivably be named `min` under the guidelines:<br class=""><br class="">func min() -> Generator.Element? // obviously only where `Generator.Element` is `Comparable`<br class="">func min(isLessThan comparator: (Generator.Element,Generator.Element)<br class="">-> Bool) -> Generator.Element?<br class="">func min<K:Comparable>(extractor: (Generator.Element) -> K) -> K?<br class="">func min<K:Comparable>(extractor: (Generator.Element) -> K?) -> K?<br class="">func min<T>(extractor: (Generator.Element) -> T, isLessThan comparator: (T,T) -> Bool) -> T?<br class="">func min<T>(extractor: (Generator.Element) -> T?, isLessThan comparator: (T,T) -> Bool) -> T?<br class=""><br class="">…and perhaps they *all* should be named `min` (and we simply let<br class="">context and type information sort it all out for us).<br class=""><br class="">But if the names should be different, what’re good choices?<br class=""><br class="">My vague concern is that having “maximally-terse” names for the<br class="">standard library functions makes it trickier to choose<br class="">"non-misleading” names for such closely-related variants.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">We are not going for maximal terseness in the standard library. When we</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">pick a name like "min" it's because of precedent and expectations.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">EG: if you go with `minValue` for the variants, to a casual reader<br class="">there’s room for confusion vis-a-vis `min` (I suspect many would<br class="">initially guess that `minValue` does what `minElement` does today, but<br class="">would guess the behavior correctly if given a choice between<br class="">`minElement` and `minValue`).<br class=""><br class="">Unfortunately for my case, I think `minFor` is a perfectly-reasonable<br class="">choice here, which undermines my concrete example (I warned you the<br class="">case wasn’t going to be very convincing).<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">It is just as you said :-)</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">But that’s the kind of vague concern I have here: that a<br class="">“maximally-terse” naming convention can be harder to extend in a way<br class="">that’s both self-consistent and not-potentially-misleading.<br class=""><br class="">But I don’t have a great suggestion for an additional guideline, and<br class="">there may be nothing serious to worry about here, either.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I think we've made it very clear that we're not going for maximal</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">terseness:</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> Clarity is more important than brevity. Although Swift code can be</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> compact, it is a non-goal to enable the smallest possible code with</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> the fewest characters. Brevity in Swift code, where it occurs, is a</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> side-effect of the strong type system and features that naturally</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> reduce boilerplate.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">—<span class="Apple-converted-space"> </span></span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">I understand you don’t think you’re going for maximal terseness, but guidelines aimed at redundancy-reduction with a lack of concern for what the linguists call “markedness” (which is amongst other things context-dependent, and thus not easy to judge in isolation).</div><div class=""><br class=""></div><div class=""><div class="">Specifically, what counts as “weak type information” will always be somewhat context-dependent. Here’s another example, this time drawn from the Objective-C import proposal: `documentFor(url: NSURL)`.</div><div class=""><br class=""></div><div class="">`documentFor(url: NSURL)` is certainly in conformance to the current guidelines.</div><div class=""><br class=""></div><div class="">However, in an application context, I’d usually want application code to *largely* avoid calling such “low-level” methods directly, in favor of wrappers defined in terms of application-level concepts, e.g. some possible examples:</div><div class=""><br class=""></div><div class="">documentFor(windowState: WindowState) // e.g. state-restoration</div><div class=""><div class="">documentFor(bookmark: BookmarkData) // e.g. user-favorites menu</div><div class="">documentFor(user: User) // e.g. a 1:1 user-document thing (consider a test-administration use case)</div><div class="">documentFor(template: TemplateDescriptor) // e.g. create-new-document from a template of some kind</div><div class="">documentFor(image: Image) // e.g. create-a-new-document containing `image` and ready for further use</div><div class=""><br class=""></div><div class="">…and so on and so forth. Note that all of the above are also in conformance with the guidelines—if `documentForURL` is wrong, then `documentForWindowState` is even more wrong!</div><div class=""><br class=""></div><div class="">So, given that I would prefer application-level code use the "application-level variants", I’m a bit stuck if I want the “application-level” variants to be easy to distinguish (visually) from the “low-level” variant: </div><div class=""><br class=""></div><div class="">- `documentFor(url: NSURL)` is out of my control, so I can’t unilaterally-demote it to `documentForURL(url: NSURL)` on my end (I can write a wrapper, but can’t hide the base method at this time...)</div><div class="">- lengthening the “application-level” names goes against the spirit of the guidelines</div><div class="">- changing the “application-level” names often feels unidiomatic (`restoredDocumentFor(windowState: WindowState)` is ok, but `bookmarkedDocumentFor(bookmark: BookmarkData)` feels awful-and-unnecessary)</div><div class=""><br class=""></div><div class="">…which wan’t a concern in Objective-C, b/c the increased verbosity kept everything uniform and easily-verifiable:</div><div class=""><br class=""></div><div class=""><div class="">- `documentForURL:`</div><div class="">- `documentForWindowState:`</div><div class="">- `documentForBookmark:`</div><div class=""><div class="">- `documentForUser:`</div><div class=""><div class="">- `documentForTemplate:`</div></div><div class=""><div class="">- `documentForImage:`</div></div><div class=""><br class=""></div><div class="">…(with the extensions likely having `prefix_` in front to boot!).</div><div class=""><br class=""></div><div class="">I do think this is going to be a bit awkward in all settings where the guidelines steer us towards having a bunch of identically-named extension methods calling through to “standard-library” functionality; in such settings what used to be adequate type-information (within the standard library context) starts to look like weak type information (in its context-of-use).</div><div class=""><br class=""></div></div></div><div class=""><div class="">I don’t think the right answer is for, e.g., the Objective-C import to uniformly start using `documentForURL`-type names; that feels like overkill.</div><div class=""><br class=""></div><div class="">I do think a loosened attitude about when-and-how to include a first-argument label will open up a lot of room to address such concerns; I suspect that the other discussions around when to use identical base names and when to use first argument labels is originating from at-least broadly-similar concerns.</div><div class=""><br class=""></div><div class="">Perhaps it can be addressed by taking the below:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Methods can share a base name when they share the same basic meaning but operate on different types, or are in different domains.<br class=""></blockquote><div class=""><br class=""></div>…and tweaking it to include a note that such methods *may* label their first argument when necessary to clarify either:</div><div class=""><br class=""></div>- the method variant (when the methods do the same thing to the point the same base name should be used, but nevertheless are meant for different-enough intents to benefit from an explicit distinction)<br class=""><div class="">- the interpretation of said argument (hopefully this is rather rare)</div><div class=""><br class=""></div></div></div></div><div class="">…but at this point I think I’ve said my bit, brought up the delegate-naming issue, and appreciate the time and consideration. The delegate convention seems to need a reboot, anyways, and should seemingly at least wait for the first review of the objective-c import discussion to conclude.</div><br class=""><blockquote type="cite" class=""><div class=""><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">-Dave</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">swift-evolution mailing list</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:swift-evolution@swift.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">swift-evolution@swift.org</a><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>