This page is no longer maintained — Please continue to the home page at www.scala-lang.org

2.8 RichInt#to

6 replies
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
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.
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: 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 [at] gmail [dot] 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.
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: 2.8 RichInt#to
On Tue, Sep 1, 2009 at 9:43 AM, Daniel Sobral <dcsobral [at] gmail [dot] 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.
Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: 2.8 RichInt#to

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.
>

David Flemström
Joined: 2009-08-10,
User offline. Last seen 42 years 45 weeks ago.
Re: 2.8 RichInt#to
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 [at] gmail [dot] 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 [dot] flemstrom [at] gmail [dot] com
Colin Bullock
Joined: 2009-01-23,
User offline. Last seen 42 years 45 weeks ago.
Re: 2.8 RichInt#to
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
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: 2.8 RichInt#to
On Tue, Sep 1, 2009 at 10:14 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] 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.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland