Range Types

[darkdrag00nv2]

Work towards onflow/developer-grants#179

[dsainati1]

Nice! I like the Range and Progression types because they are nicely extensible; we could later allow people to iterate over any kind of comparable type (strings, addresses, etc) if we lift the restriction that the type argument here be an Integer. A couple of suggestions though:

I don't think Range and Progression actually need to be different types, since a Range is just a special case of the more general Progression type where the step is a specific default value (in this case 1 or -1). I suggest that we combine these into one Range type that can be given a step if the developer wishes, but otherwise uses these defaults.

Additionally, I think we don't need the specific downTo operator; all this is really doing is making the step negative.

What if instead the range was always defined with .., and the sign of the step is automatically inferred from whether the start or end value is greater. We could also imagine a syntax like let range = x, y .. z where the start of this range is x, the end is z, and the step is y-x. Rephrased, developers could define the sequence by giving it a start and end, and if they want the step to be something other than +/- 1, they can define the second element of the range and the step is automatically inferred based on that?

[turbolent]

Nice! Thank you for writing up this proposal 👍

[darkdrag00nv2]

@turbolent @dsainati1 Thanks for your review comments. I agree with all of the suggestions and will modify the FLIP with the following new proposal:

We will not have operators to create a *Range. We can just have standard library functions. There will be two types & constructors: InclusiveRange and ExclusiveRange. I'll revert the lexer/parser changes I made in my draft PR: onflow/cadence#2523. This would eliminate the need of operators & all the readability concerns with it.

The only source of confusion for me is whether we want to unify Range and Progression types as @dsainati1 proposed (originally proposed - onflow/cadence#2482 (comment)) or keep them separate as @turbolent proposed (see onflow/cadence#2482 (comment)).

For unified, the constructors will be InclusiveRange, InclusiveRangeWithStep, ExclusiveRange & ExclusiveRangeWithStep due to lack of function overloading.

For separate, the constructors will InclusiveRange, InclusiveProgression, ExclusiveRange & ExclusiveProgression.

[dsainati1]

IMO it's better to have them be one type, if only because the names are clearer. IMO the function name InclusiveRangeWithStep is much clearer than InclusiveProgression, so I prefer this naming scheme in general.

[dsainati1]

Nice! I like this proposal a lot more after the changes, it seems like it's going to be a nice feature.

[darkdrag00nv2]

Updated the FLIP

• Merged InclusiveRange and InclusiveRangeWithStep into a single constructor function InclusiveRange with step being a non-required argument. Did a similar change for ExclusiveRange.
• Renamed endInclusive and endExclusive in the two types to be end since the name of the type is indicative enough
• Made empty ExclusiveRange creation a runtime error.
• Renamed member field length to count

[bjartek]

Can we have a helper method that has some defaults? For instance for IntRange having it as step 1 is a start. Also what about specifying length and not end?

[SupunS]

The overall design looks good to me!

[darkdrag00nv2]

@bjartek

For instance for IntRange having it as step 1 is a start.

The step argument in the constructor is optional. It already supports step of 1 or -1.

Also what about specifying length and not end?

Sounds useful but I think the argument against count from @turbolent also applies here. This might not be useful if we drop the Integer bound. So may be we can revisit and add this at a later point if there is demand.

[SupunS]

Nice, LGTM!

[dsainati1]

Looks good to me! Thanks for the hard work

[turbolent]

Nice! 🚀

[turbolent]

Let's leave this open for another week to invite additional feedback. If there's no additional feedback the FLIP is ready to get accepted and merged 🎉