> On 2 Jul 2016, at 14:19, Anton Zhilin via swift-evolution
> <[email protected]> wrote:
>
> Diego Barros via swift-evolution <swift-evolution@...> 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 ;)_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
