Impl Default for ranges

[c410-f3r]

Couldn't find an issue about it.

Range and friends probably can implement Default if Idx: Default. For example, the following would be possible:

#[derive(Default)]
struct Foo(core::ops::RangeToInclusive<u64>);

let _ = [1, 2, 3].get(core::ops::Range::default());

core::ops::RangeFrom::<u8>::default().take(20).for_each(|x| { dbg!(x); });

fn stuff<T: Default>() { let instance = T::default(); ... more stuff }
stuff::<core::ops::RangeTo<f32>>();

Maybe there are some concerns about safety or misunderstandings?

[rust-highfive]

r? @joshtriplett

(rust_highfive has picked a reviewer for you, use r? to override)

[clarfonthey]

Although empty makes sense, how could we be sure that starting and ending at zero is the best choice?

[taiki-e]

In this PR's implementation, it seems that the defaults of Range/RangeTo/RangeInclusive/RangeInclusiveTo are "empty", the defaults of RangeInclusive/RangeInclusiveTo are "the first element" and the defaults of RangeFrom/RangeFull are "all elements".

I'm not sure if it makes sense to implement default on ranges that have bounds only at either the start or end.

EDIT: fixed wrong comment, defaults of RangeInclusive/RangeInclusiveTo is actually "the first element".

EDIT2: this is only for unsigned integer (#73197 (comment))

[c410-f3r]

Not sure if it is possible to have optioned implementations because the implications and semantics will vary depending on the Idx type or the selected structure, in other words, the user is aware of what he is doing. Which is different from the implicit consequences of #27186.

[Dylan-DPC-zz]

r? @Amanieu

[Amanieu]

I don't think Default really makes sense for ranges. Is there a specific use case that this would enable?

[c410-f3r]

There are four listed use-cases and I personally have a trait Foo that expects Foo: Default and one of its implementations should be core::ops::Range, effectively forcing a custom struct YetAnotherStructToEncapsulateYetAnotherCoreType(core::ops::Range<f64>); wrapper.

IMHO, these implementations have no side-effects.

[Mark-Simulacrum]

The listed use cases don't suggest obvious defaults (at least to me). Do you have a case that's less cut down (i.e., a real world example)? I don't think empty ranges are obviously "default" to me.

[c410-f3r]

Implementation

A default instance is, in my option, an independent constant value and if the listed examples are starting and ending as zero, it is because their Idx types are also zero (<u64 as Default>::default() == 0). Not sure if it is something that can be modified in a generalized way, let's suppose that "empty" is not a good default, then what the default should be like if Idx is not known? Manual hard-coded implementation using declarative macro or a type bound constraint isn't a good alternative because it ceases user freedom. For example:

// For whatever reason, <Range<u32> as Default>::default() = 0..u32::MAX is a good default
impl Default for Range<u32> { fn default() -> Self { 0..u32::MAX } }

// Problem: There isn't a Range implementation for arbitrary types
#[derive(Default)]
struct FancyDecimalType;
#[derive(Default)]
struct UserTypeWithRange(Range<FancyDecimalType>); // error!

// Because: Generic implementation will conflict with <Range<u32> as Default>
impl<T: Default> Default for Range<T> { fn default() -> Self { Default::default()..Default::default() } } // error!

// Bound constraints suffer the same problem, suppose an imaginary std Number trait that has `min()` and `max()`
impl<T: Number> Default for Range<T> { fn default() -> Self { T::min()..T::max() } }

// As a consequence, it also won't be possible to have a generic implementation for Range<T>

As previously said, a generic impl<T: Default> for Range*<T> { ... } gives freedom and the user should be aware of what kind of instance value Range(From|To|ToInclusive) is going to have based on T: Default.

Use-case

If all given explanations weren't enough, then I will try to explain a hopefully "real-world" use-case: I have a project that solves nondeterministic polynomial problems which is basically composed of trait Solution, trait Domain<S> and trait Criteria. Most problems have variables represented as vectors of continuous numbers ([1.0, 2.0, 3.0]) with their respective contiguous domains represented as vectors of continuous ranges ([0.0..10.0, 0.0..5.0, 1.0..3.0]), therefore:

// Just a simplification. The real code were made using declarative macros and num
impl Solution for [f64; 1] { ... }
impl Domain<[f64; 1]> for [core::ops::Range<f64>; 1] { ... }

All posterior operations don't known what Solution, Domain or Criteria are because they are abstracted away in a Problem<S: Solution, D: Domain, C: Criteria> { ... } structure and it is important to have a default dummy instance to evaluate a solver's performance/quality or as an intermediate state between the conversion of different constrained, unconstrained, single or multi-objectives problems.
With a expected Problem< ... >: Default and without Range<T>: Default, every single problem definition that uses ranges as domains will have to create a cumbersome and duplicated wrapper:

pub struct RangeWrapperBecauseOfDefaultDomain<T>(pub core::ops::Range<T>);

impl<T> Default for RangeWrapperBecauseOfDefaultDomain<T>
where
  T: Default
{
  fn default() -> Self {
    Self(T::default()..T::default())
}

This effect can be minimized by other means but like the subtitle says, it is just an additional use-case that hopefully can be interpreted as a more "real-world" example.

[Amanieu]

I can see the reasoning behind this and tentatively agree that we should add Default.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• let's not do for RangeFrom, RangeTo, RangeInclusive, RangeToInclusive resolved by Impl Default for ranges #73197 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[scottmcm]

The fact that 0..0 and 0..=0 are so different makes me somewhat skeptical here. Even in the domain example, it doesn't seem obvious that the Range<T>: Default would be useful -- defaulting to an empty domain (0..0) doesn't seem like what would be wanted, nor would defaulting to a singleton domain (0..=0).

I'll note that, for example, std::ops::Bound doesn't impl Default either.

[dtolnay]

I am skeptical of some of these too. I am definitely on board with the impl for RangeFull. I am also on board with an impl for Range, which does the equivalent of default()..default(). I think I would prefer to leave out the rest of the impls: RangeFrom, RangeTo, RangeInclusive, RangeToInclusive.

[c410-f3r]

core::ops::Bound can be 3 different things and a default value wouldn't make sense for every scenario, thus the reason why #[derive(Default)] can't be applied to enums. This PR only touches concrete ranges structures that clearly express what they were made for.

As previously said, "empty" ranges are just a consequence of a generic impl<T: Default> Default for Range(From|To|ToInclusive)<T> that specific hand-picked implementations would break due to conflicting resolution.

Regarding on what is a "good" default, I can say IMHO that it will vary from person to person.

[dtolnay]

@rfcbot concern let's not do for RangeFrom, RangeTo, RangeInclusive, RangeToInclusive

Per #73197 (review).

[SimonSapin]

In this PR's implementation, it seems that the defaults of Range/RangeTo/RangeInclusive/RangeInclusiveTo are "empty", the defaults of RangeInclusive/RangeInclusiveTo are "the first element" and the defaults of RangeFrom/RangeFull are "all elements".

Only for unsigned integer

[dtolnay]

@rfcbot resolve let's not do for RangeFrom, RangeTo, RangeInclusive, RangeToInclusive
@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[avl]

Since Vec defaults to an empty Vec, isn't it only logical that Range would default to en empty Range?

I personally think it is often convenient to have default implemented for as many types as possible. For instance, it allows resize on a Vec. Default is needed even if the vector is only ever shrunk in practice.

[scottmcm]

Since Vec defaults to an empty Vec, isn't it only logical that Range would default to en empty Range?

Let say it is: then wouldn't it also be "only logical" that the other kinds of RangeBounds would also default to an empty range? Which of course can't happen: It's straight impossible for RangeFull, RangeFrom, RangeTo, and RangeToInclusive. And doing it for RangeInclusive either means a new trait (because Default::default()..=Default::default() is typically non-empty) or forcing forever the "there's an extra flag to ignore the fields" implementation of RangeInclusive.

And the other kind of RangeBounds in std is (Bound, Bound), but @c410-f3r just argued earlier that Bound shouldn't be Default, which means that that pair can't be Default either.

For instance, it allows resize on a Vec. Default is needed even if the vector is only ever shrunk in practice.

resize doesn't use Default; nor does resize_with. resize_default does, obviously, but that's currently deprecated. Not to mention that there's always just truncate for shrinking...

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[dtolnay]

@bors r+

[bors]

📌 Commit c375692 has been approved by dtolnay

[avl]

Since Vec defaults to an empty Vec, isn't it only logical that Range would default to en empty Range?

Let say it is: then wouldn't it also be "only logical" that the other kinds of RangeBounds would also default to an empty range? Which of course can't happen: It's straight impossible for RangeFull, RangeFrom, RangeTo, and RangeToInclusive. And doing it for RangeInclusive either means a new trait (because Default::default()..=Default::default() is typically non-empty) or forcing forever the "there's an extra flag to ignore the fields" implementation of RangeInclusive.

All good points! I think I overstated things when I said "only logical". I think it's not "obvious" that the Range types should implement Default. But I still think it would be useful, and not that much more surprising than Vec or u32 implementing Default.

resize doesn't use Default; nor does resize_with. resize_default does, obviously, but that's currently deprecated. Not to mention that there's always just truncate for shrinking...

Ah, I didn't know about truncate!

My use case was I had a program which processed lots of data in parallel in many threads. It could use a thread pool of N threads. The program had a Vec<T> of length N for scratch data. Each worker thread needed to use some memory for its processing, and this scratch data was stored in the Vec. If the number of worker threads was changed, the Vec needed to be resized.

I wanted to automatically resize the Vec to the correct number, and required T:Default so there was value to use for any new elements. If type T anywhere contained a Range, it would be inconvenient because it couldn't as easily implement Default in that case. Reading what I wrote I realize that my argument isn't super-convincing, but I at least wished that Default was implemented for all types where it can be argued that one value is more default than any other value. Such as the u32 0, the empty Vec, and conceivably, the range 0..0 .