[Pitch] range.contains(anotherRange)

Hi,

Recently I needed to implement `contains` methods to check if a range
contains another range. I think those are basic operations and suitable for
the standard library.

Although it may seem easy to implement such `contains` methods whenever we
need them, their precise specifications are too complicated to do so.

e.g.

let a: ClosedRange<Int> = 2...7
a.contains(3...5) // `true`
a.contains(3...7) // also `true`
a.contains(3..<8) // still `true` because all values contained in `3..<8`
are also in `a`
a.contains(3..<9) // `false`

let b: ClosedRange<Float> = 2...7
b.contains(3...5) // `true`
b.contains(3...7) // `true`
b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not contained
in `a`

let c: Range<Float> = 2..<7
c.contains(3...5) // `true`
c.contains(3..<7) // `true`
c.contains(3...7) // `false` because 7.0 is not contained in `a`

My experimental implementation is here:
https://github.com/koher/range-contains
(Currently does not support one-sided ranges)

What are your thoughts about them?

···

--
Yuta

For consistency, the name for this function would be `isSuperset(of:)`, and
it would be equally interesting to have `isStrictSuperset(of:)`,
`isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all
currently available for types that conform to `SetAlgebra`.

···

On Tue, Aug 8, 2017 at 9:40 PM, Yuta Koshizawa via swift-evolution < swift-evolution@swift.org> wrote:

Hi,

Recently I needed to implement `contains` methods to check if a range
contains another range. I think those are basic operations and suitable for
the standard library.

Although it may seem easy to implement such `contains` methods whenever we
need them, their precise specifications are too complicated to do so.

e.g.

let a: ClosedRange<Int> = 2...7
a.contains(3...5) // `true`
a.contains(3...7) // also `true`
a.contains(3..<8) // still `true` because all values contained in `3..<8`
are also in `a`
a.contains(3..<9) // `false`

let b: ClosedRange<Float> = 2...7
b.contains(3...5) // `true`
b.contains(3...7) // `true`
b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not
contained in `a`

let c: Range<Float> = 2..<7
c.contains(3...5) // `true`
c.contains(3..<7) // `true`
c.contains(3...7) // `false` because 7.0 is not contained in `a`

My experimental implementation is here:
https://github.com/koher/range-contains
(Currently does not support one-sided ranges)

What are your thoughts about them?

--
Yuta

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of SetAlgebra — why must something implementing SetAlgebra be able to be initialized as empty or from a finite sequence?

···

On Aug 8, 2017, at 11:23 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

For consistency, the name for this function would be `isSuperset(of:)`, and it would be equally interesting to have `isStrictSuperset(of:)`, `isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all currently available for types that conform to `SetAlgebra`.

On Tue, Aug 8, 2017 at 9:40 PM, Yuta Koshizawa via swift-evolution <swift-evolution@swift.org> wrote:
Hi,

Recently I needed to implement `contains` methods to check if a range contains another range. I think those are basic operations and suitable for the standard library.

Although it may seem easy to implement such `contains` methods whenever we need them, their precise specifications are too complicated to do so.

e.g.

let a: ClosedRange<Int> = 2...7
a.contains(3...5) // `true`
a.contains(3...7) // also `true`
a.contains(3..<8) // still `true` because all values contained in `3..<8` are also in `a`
a.contains(3..<9) // `false`

let b: ClosedRange<Float> = 2...7
b.contains(3...5) // `true`
b.contains(3...7) // `true`
b.contains(3..<8) // `false` because { x | 7.0 < x < 8.0 } is not contained in `a`

let c: Range<Float> = 2..<7
c.contains(3...5) // `true`
c.contains(3..<7) // `true`
c.contains(3...7) // `false` because 7.0 is not contained in `a`

My experimental implementation is here:
https://github.com/koher/range-contains
(Currently does not support one-sided ranges)

What are your thoughts about them?

--
Yuta

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

For consistency, the name for this function would be `isSuperset(of:)`, and
it would be equally interesting to have `isStrictSuperset(of:)`,
`isSubset(of:)`, `isStrictSubset(of:)` and `isDisjoint(with:)`--all
currently available for types that conform to `SetAlgebra`.

Thank you for your feedback. It certainly seems better to rename `contains`
to `isSuperset(of:)`. Also I'll try to implement `isStrictSuperset(of:)`
and so on.

···

2017-08-09 12:23 GMT+09:00 Xiaodi Wu <xiaodi.wu@gmail.com>:

--
Yuta

It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks
the required initializers. Is there anything that can be done about this?
Actually, it makes me wonder whether those initializers should even be a
part of SetAlgebra — why must something implementing SetAlgebra be able to
be initialized as empty or from a finite sequence?

I am not sure if removing initializers from `SetAlgebra` does not cause any
problems in the standard library, it seems reasonable for me if range types
could adopt `SetAlgebra`.

···

2017-08-09 12:50 GMT+09:00 Robert Bennett <rltbennett@icloud.com>:

--
Yuta

I am not sure if removing initializers from `SetAlgebra` does not cause any
problems in the standard library, it seems reasonable for me if range types
could adopt `SetAlgebra`.

`SetAlgebra` contains some mutating methods like `insert`, `remove`,
`formUnion`. It means it is impossible for range types to adopt
`SetAlgebra`. In addition, even if we remove such methods from
`SetAlgebra`, because the return type of something like `union` is `Self`,
`2..3.union(5...7)` cannot be represented.

···

--
Yuta

Terms of Service

Privacy Policy

Cookie Policy