> On Jun 24, 2016, at 11:14 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> [...] what I'm trying to point out here--not mentioned previously--is that
> one purported major benefit of `where` (putting everything on one line) is
> inapplicable to the Swift stdlib's own style as well as those of others.
That's like saying that you can't use long method names imported from ObjC in
Swift. Why can't you use
for anchor
in wall.anchors
where boundsRect.contains(anchor.origin)
or similar, if you need to fit within the 80 chars - just like you'd do with a
compound if statement that exceeds 80 chars.
The major benefit isn't saving a line (though it's 3 unless you're willing to
add { continue } on the same line), but to express your intend to filter the
array right within the for-in statement.
When you look around someone else's code, you immediately see that the person
is only going through anchors without bounds without the need to examine the
loop's body, which may be collapsed (hidden) by the editor.
> I think you made your point clearly in the discussions and proposal. Please
> allow other people to have their own opinions in this review :), otherwise it
> is not a review imo.
>
> You may note that I've confined my comments to particulars raised by others'
> comments. And, FWIW, I haven't actually reviewed the proposal, so I'm not
> sure how you know how I feel about it.
>
>
>> 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.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> 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
