I notice now that the proposal does define how the change interacts with type declarations, in the grammar section. However, I still see that as an even worse change than in the function case.
Jon Shier > On May 14, 2016, at 1:05 AM, Jon Shier <[email protected]> wrote: > >> * What is your evaluation of the proposal? > > -1 > > No one has been able to explain how this change improves readability, it just > seems like it’s supposed to be self evident. I would argue that it makes the > generic definitions less readable by separating declarations and their > relevant where clauses. At best this change just moves the already unreadable > mass of text elsewhere, where it’s still unreadable. Furthermore, it trades > this supposed readability of generic parameters for decreased readability of > the actual function signature, since that signature’s now buried between the > generic definitions and the where clauses. This is especially bad when > declaring a single generic type that can easily fit on a single line, such as: > > func something<T: Decodable where T == T.DecodedType>(with something: T) -> > String > > turns into this, which is less readable to me, as it hides important > information between the generic information: > > func something<T: Decodable>(with something: T) -> String where T == > T.DecodedType > > Also, this proposal doesn’t explain how the definitions for generic types > would change. Using the proposed grammar would be even worse on types. From: > > final class NetworkOperation<T: Decodable where T == T.DecodedType>: > Operation,… { > > to: > > final class NetworkOperation<T: Decodable>: Operation,… where T == > T.DecodedType { > > The additional conformances types can have make this an especially bad use > case for this proposal. > >> * Is the problem being addressed significant enough to warrant a change >> to Swift? > > It can be a problem, but I don’t see how this proposal fixes it. Appropriate > code styling, whether manual or provided by an IDE, could provide much better > readability than this proposal ever could. > >> * Does this proposal fit well with the feel and direction of Swift? > > Changes proposed for “readability” need to be closely scrutinized, as one > programmer’s readable and another’s Perl. I don’t think this proposal meets > the high standard this list has tried to set for things to the language. > >> * If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > > Java and C++’s generics, which are rather different. And despite what they > may have intended, I don’t think generics in either language are used as much > as in Swift. > >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? > > Read the proposal, the thread thus far, and considered my response. > > > > Jon >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
