[swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Xiaodi Wu]

On Fri, Jun 24, 2016 at 2:26 PM, Charlie Monroe <charlie at charliemonroe.net>
wrote:

>
> On Jun 24, 2016, at 9:00 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Jun 24, 2016 at 1:56 PM, Sean Heber <sean at fifthace.com> wrote:
>
>> > On Jun 24, 2016, at 1:30 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <wjs at mac.com> wrote:
>> > On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <xiaodi.wu at 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.
>>
>> I honestly don’t believe that this a common style in the Cocoa community.
>
>
> We're talking about the Swift community here, and Swift stdlib would be a
> good starting point as to what is a common or at least accepted style; it
> uses 80-character lines.
>
>
> While it does, it makes sense only for readability purposes of the
> documentation. For example, I see absolute no reason why to split
> https://github.com/apple/swift/blob/master/stdlib/public/core/StringBuffer.swift#L233 into
> two lines.
>
> It makes the code less readable.
>
> 80-char style made sense in C, where everything is pretty much top-level.
> But given that you declare a class, within which you declare another class,
> within which you declare methods, the first level of the method indentation
> is at level 3, which given 4 spaces per tab gives you 12 characters
> already. Adding a few levels (for-cycle + an if statement within the for
> cycle) gives you 20 characters of just whitespace (1/4 of the allocated 80
> chars per line).
>
> Which is why I don't believe this code style is valid in a modern language.
>

This is one style that some very intelligent people use in Swift. I'm not
going to debate what styles are "valid."

My personal guess is that it should be upped to e.g. 160 chars per line -
> that kind of makes sense. There is no particular reason other than historic
> why we're still using 80 chars per line.
>
>
>
>> I’m not a member of the “old guard” having only come into this world 10
>> years ago with the iPhone, but just take a look at this delegate method in
>> Objective-C:
>>
>> - (void)locationManager:(CLLocationManager *)manager
>> rangingBeaconsDidFailForRegion:(CLBeaconRegion *)region withError:(NSError
>> *)error;
>>
>> That’s well over 80 characters all by itself. This fits on my screen in a
>> single line - and I work on a 15” MBP with room for my dock always visible
>> on the side along with Xcode’s sidebar open! On a typical desktop-sized
>> screen, 80-col lines must be comically short.
>>
>> I don’t know why it should be assumed that people are adhering to a
>> so-called standard that dates back to terminal screens that didn’t have
>> color.
>>
>>
>> > 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.
>>
>> Again, I dispute the idea (having no data but my own :P) that 80-col
>> limits are common in this community.
>>
>> l8r
>> Sean
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/494e5197/attachment.html>