I understand the concern. To me, the answer is clearly yes. The language cannot be considered in isolation from its use cases; imagine UIKit written in Swift.
You want the developers to be able to quickly understand which table view delegate methods they need to implement, and what the contract is (are cells editable or non-editable by default?). We need the same thing for our own UIKit-style controls we're writing today (and we don't want to be limited to @objc types when doing that — those are particularly ill-suited for the return values of optional delegate methods; I often want a CGFloat? or a enum). I don't see this as a separate faculty as much as a shorthand, similar to how T? is a shorthand for Optional<T>. The general opinion on shorthands varies from “there should be exactly one way to do everything” Python-style to “the language should help the developer express themselves” Ruby/Perl-style. I personally am firmly in the “Ruby camp” here, so I'm all for use case-specific shorthands for general facilities. You, sir (together with your dream team), should probably pick an official stance on this matter. :-) A. On 4 Apr 2016 04:15 +0600, Yuval Tal<[email protected]>, wrote: > For readability and specifically in this case, I think it does make sense > IMHO. > > On Sunday, April 3, 2016, Chris > Lattner<[email protected](mailto:[email protected])>wrote: > > > > > On Apr 3, 2016, at 10:40 AM, Andrey > > > Tarantsov<[email protected](javascript:_e(%7B%7D,'cvml','[email protected]');)>wrote: > > > > Protocol requirements with default (no-op) implementations already > > > > satisfy that design goal, no? > > > Chris, as we've discussed in a thread that I think got forked from this > > > one: > > > > > > Yes, they do technically, but it would be nice to both: > > > > > > 1) make it an obvious documented part of the signature, possibly > > > including the default return value > > > > > > 2) possibly make it less verbose by getting rid of the explicitly spelled > > > out protocol extension > > Right, but “more is worse” when it comes to language design.Having a "more > > general" facility that greatly overlaps with a “more narrow” facility > > always makes us question whether it is worth the complexity to have both. > > > > -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
