On Fri, Jun 24, 2016 at 1:38 PM, Tony Allevato <allev...@google.com> wrote:
> On Fri, Jun 24, 2016 at 11:30 AM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <w...@mac.com> wrote: >> >>> On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> >>> Not a practitioner of 80-character line limits, I take it? >>> >>> >>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping >>> for most cases. I’ll add newlines if I think it adds to clarity, but in >>> general I don’t want to code like i’m still on a Wyse WY-50. >>> >> >> Of course, to each their own style--I certainly wouldn't want Swift to >> force everyone to write lines of certain lengths. But 80-character lines is >> a common style, and I would say that a corollary of "to each their own" is >> that Swift's grammar should be usable and useful whether or not you adhere >> to such style choices. >> >> If the chief advantage of `where` is that it (quoting someone above) >> allows one to "understand as much as possible about the control flow of >> the loop from a single line of code," then we ought perhaps to question its >> appropriateness when the majority of its benefits [by which I mean, based >> on your examples and Sean's, more than half of the instances in which it is >> used] cannot be realized in a very common coding style. >> > > IMO, we shouldn't be talking about "a single line of code" so much as "a > single cohesive construct". What's important to me isn't the line length or > whether the "where" part has to wrap onto another line, it's the number of > potentially divergent constructs I have to parse mentally in order to > determine the meaning of the loop. > > With "for-in-where", it's three: > > for item(1) in someCollection(2) where someCondition(3) > > With the alternatives suggested using if/guard/continue/break, it's more > than that: > > for item(1) in someCollection(2) { > [if | guard...else](3) someCondition(4) { > [continue | break](5) > } > } > > I have to be more careful now interpreting the meaning of this loop > because both or either of if/guard or continue/break can invert its > meaning, where was "for-in-where" is concise and clear. > And if `while` is added along with `where`, all this goes out the window. > Doing .lazy.filter{...} is slightly cleaner than this, but still suffers > from the disadvantage that it's very easy for newcomers to leave out the > "lazy" part and accidentally write poorly performing code, and to the > argument that "where" is considered confusing by some users, I would argue > that it's easier to explain how it works than why "lazy" is necessary in > this context. > Clearly, eagerly filtering results in slower code, but based on the examples provided above I don't imagine any of them would turn into "poorly performing" code with eager filtering. In fact, I see some that could run a little faster with some refactoring along these lines. In any case, optimizing performance comes after correctness; a user who can't grasp `lazy` can nonetheless still write useful, correct code. _______________________________________________ > swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution