-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: please consider implementing new()
constructor and Default
trait
#293
Comments
The point being made in the issue you linked to was that there isn't a good sense of what "default" is. Having a default of "the current naive time" for NaiveDateTime or "the current tz-aware local time" for DateTime are both sensible options in addition to what you mentioned. When deriving |
Sure, I suggest to implement the #[derive(Debug, Default)]
struct MyStruct {
name: String,
content: String,
date: NaiveDate,
}
impl MyStruct {
fn new() -> Self {
Self::default()
}
} |
The thing that prevents us from implementing default is that there is no "obvious" default. Either one of several possible values of Zero or "now" both make sense. You can either implement Default manually or do something like: struct DefaultNow(pub NaiveDate);
impl Default for DefaultNow {
fn default() -> DefaultNow {
DefaultNow(Utc.today().naive_utc())
}
} Which will allow you to derive Default on your structs that contain a DefaultNow. |
Three small observations if I may; since using Default requires opting in from higher level code, there seems to be little chance of negative effects if the wrong arm of the choice (0 vs now()) were to be made. Secondly, if an arbitrary choice were made, for the folk for whom it is not suitable, a wrapper type can still be used to get the desired customisation. Lastly, for test code having deterministic defaults is highly desirable, so I would very much encourage a zero-valued default implementation of default, leaving |
Exactly right @rbtcollins. For some reason, many Rust crate maintainers I encountered are apprehensive because they're unsure which default to pick. That‘s beside the point though. Why would it matter which one among a set of reasonable options you pick? |
Sometimes moving forward "wrongly" is better than not moving forward at all. For very large structures, having to implement Default can become cumbersome and reminds me of XML and Java boilerplate. I would argue for picking one default and then letting it be. That said, an addendum to @quodlibetor 's solution for structures that are more complex (e.g. nested structures). One only needs to include
|
I'll add my support for implementing Default for
Regarding
|
I can see how the lack of a |
Perhaps not a default() or even a new() as their meanings would be ambiguous, but it would be somewhat useful to have a few DateTime constructors that can represent say unix epoch 32-bit zero and max, and 64-bit zero, max. The use case here is that I'm trying to coalesce an optional DateTime as unix timestamp zero, the idea being that if no datetime is specified in a json file, then it will coalesce as unix zero, effectively making a file date search filter have a meaning of "all time". I think there may be other use cases as well. The alternative in some cases is to do something like DateTime::parse_from_rfc2822("0000-01-01T00:00:00-00:00").unwrap() Or in every case we run into the optional, we have to do if let Some(t) {
...
} else {
...
} Both of which feel a bit kludgy (the later contributing to the big nested ifs we have to deal with in the case of too many optionals) |
I know that this has been discussed before, but please consider what suggested in the Rust API guidelines:
https://rust-lang-nursery.github.io/api-guidelines/interoperability.html
https://rust-lang-nursery.github.io/api-guidelines/predictability.html
For a time type, I think its natural default value should be 0. For a date type, IMHO day 1 of month 1 of year 0 is a reasonable default value as well. Being able to derive the
Default
trait when defining a custom type which includes achrono
type would of course be very convenient.The text was updated successfully, but these errors were encountered: