[swift-evolution] Proposal: Remove the underscore and `in`for `for` loop
Haravikk
swift-evolution at haravikk.me
Sun Jul 3 06:26:17 CDT 2016
> On 2 Jul 2016, at 14:19, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
>
> Diego Barros via swift-evolution <swift-evolution at ...> writes:
>
>> for 1...10 {
>> // do something 10 times
>> }
>
> Firstly, this should be delayed to post-Swift 3.
> Secondly, I tend to vote for generalization and simplification of Swift
> syntax. For example, I voted to replace 'default' with 'case _'. In this
> case, I also prefer more general syntax. -1 from me.
Does this idea apply in the same way? While "for _ in foo" and "for foo" would be equivalent, usually the underscore is used to indicate intent to avoid mistakes, which is why we wouldn't to be able to just use "case" on its own to represent match all, as it could be a case statement that the user didn't finish, the underscore in this case makes it clear that yes, what the user wants to do is ignore the element(s) themselves.
However, unlike the switch case, for omitting the underscore to represent a mistake you'd have to:
Forget the underscore
Forget the "in" keyword
Use a variable that should have been shadowed but wasn't, resulting in a subtle error.
I specify number 3 because if you use a variable that doesn't exist it will produce an obvious error. While the three are possible, they seem highly unlikely in combination.
That said, there is an argument to be made that this change would be inconsistent with using a result:
foo.someMethod() // warning, unused result
let _ = foo.someMethod() // result explicitly ignored
I'd possibly argue that a sequence is implicitly meant to have its results used, so they should be explicitly ignored for consistency's sake.
So… I like the short-form, but I like consistency, so I think I've manoeuvred myself into being a +0.1 or so ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160703/048c6548/attachment.html>
More information about the swift-evolution
mailing list