[swift-evolution] Feature proposal: Range operator with step
Thorsten Seitz
tseitz42 at icloud.com
Thu Apr 7 01:26:40 CDT 2016
> Am 06.04.2016 um 23:03 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
>
>
>> on Wed Apr 06 2016, Erica Sadun <swift-evolution at swift.org> wrote:
>>
>> On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> Guidance:
>>
>> When using odd integer literals to produce an even number sequence,
>> prefer the `...` operator to the `..<` operator and change your ending
>> literal to an even number.
>>
>> I don't think you can fix counterintuitive behavior with guidance.
>>
>> (1..<199).striding(by: -2) is the first way I'd reach for to express
>> 197, 195, ..., 3, 1
>>
>> Yes, but you can with warnings and fixits.
>>
>> * The compiler should issue a warning for any use of
>>
>> (n..<m).striding(by: v | v < 0) | n, m, v : Integer
>>
>> with a fixit of "replace (n..<m) with (n...m - 1)" regardless of
>> whether n or m is known at compile time
>>
>> * If v cannot be known at compile time, I think the compiler should
>> always prefer ... to ..<.
>>
>> * The compiler should not allow
>>
>> (n..<m).striding(by: v | v < 0) | n, m, v: floating point types
>>
>> where v is known at compile time to be a negative constant. There should
>> also be a runtime precondition that raises a fatal error should a negative
>> v be used with a half-open interval.
>
> You can lessen the impact of any design choice by adding warnings and
> fixits, but I'm pretty sure it's better to make a choice that doesn't
> require them.
Absolutely! Having to add warnings and fixits just demonstrates that the design is confusing.
-Thorsten
More information about the swift-evolution
mailing list