2.8 RichInt#to

While I generally agree with all the principles, I don't think they apply to Range.Inclusive. Since Range is an integer range class, the only difference between an inclusive range and one which is exclusive on the upper bound is the parameters used to create the range. That being the case, I consider externalizing "inclusive" is exposing private data, and, therefore, personally approve of the change.   Note that Range.Inclusive has been deprecated, so you can use "1 to 5" -- what you can't, or shouldn't, use is Range.Inclusive.
On Tue, Sep 1, 2009 at 10:47 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

I've noticed that in 2.8, RichInt implicit to now returns just Range instead of Range.Inclusive. Any reason for that?
It's problematic to me because I have parameters that need to be Range.Inclusive and I now cannot use the "1 to 5" syntax. Furthermore it seems to violate the principle of return values being as specific as possible, i.e. I'm losing type information.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

On Tue, Sep 1, 2009 at 9:43 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

While I generally agree with all the principles, I don't think they apply to Range.Inclusive. Since Range is an integer range class, the only difference between an inclusive range and one which is exclusive on the upper bound is the parameters used to create the range. That being the case, I consider externalizing "inclusive" is exposing private data, and, therefore, personally approve of the change.   Note that Range.Inclusive has been deprecated, so you can use "1 to 5" -- what you can't, or shouldn't, use is Range.Inclusive.

So if I require an inclusive range, I'm left with no choice but to runtime check it? Seems odd for a type-safe language.

Can you explain why you require an inclusive range?

2009/9/1 Nils Kilden-Pedersen :
> On Tue, Sep 1, 2009 at 9:43 AM, Daniel Sobral wrote:
>>
>> While I generally agree with all the principles, I don't think they apply
>> to Range.Inclusive. Since Range is an integer range class, the only
>> difference between an inclusive range and one which is exclusive on the
>> upper bound is the parameters used to create the range. That being the case,
>> I consider externalizing "inclusive" is exposing private data, and,
>> therefore, personally approve of the change.
>>
>> Note that Range.Inclusive has been deprecated, so you can use "1 to 5" --
>> what you can't, or shouldn't, use is Range.Inclusive.
>>
>
> So if I require an inclusive range, I'm left with no choice but to runtime
> check it? Seems odd for a type-safe language.
>

p, li { white-space: pre-wrap; }Is there a situation where you need to be able to tell the difference?

Please remember that "1 to 5" (inclusive) yields exactly the same thing as "1 until 6" (exclusive), so I really don't understand why you would want to force an user to use an inclusive range.

On Tuesday 01 September 2009 17:07:44 Nils Kilden-Pedersen wrote:
> On Tue, Sep 1, 2009 at 9:43 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
> > While I generally agree with all the principles, I don't think they apply
> > to Range.Inclusive. Since Range is an integer range class, the only
> > difference between an inclusive range and one which is exclusive on the
> > upper bound is the parameters used to create the range. That being the
> > case, I consider externalizing "inclusive" is exposing private data, and,
> > therefore, personally approve of the change.
> >
> > Note that Range.Inclusive has been deprecated, so you can use "1 to 5" --
> > what you can't, or shouldn't, use is Range.Inclusive.
>
> So if I require an inclusive range, I'm left with no choice but to runtime
> check it? Seems odd for a type-safe language.

David Flemström
david.flemstrom@gmail.com

Once the range has been created, what's the difference between inclusive and exclusive (given that it's integer-based)?

scala> val r1 = 1 to 5
r1: Range = 1, 2, 3, 4, 5

scala> val r2 = 1 until 6
r2: Range = 1, 2, 3, 4, 5

scala> r1 == r2
res0: Boolean = true

- Colin

On Tue, Sep 1, 2009 at 10:14 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Can you explain why you require an inclusive range?

Because it fits the semantics of what I'm trying to do.

But ok, I get the point.