[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