Earlier quoted context omitted.
It's implied. Here is the full syntax. > let time: Timestamp = "2024-07-11T01:14:00Z".parse:: ()?;
That :: thing at the end is called a turbofish. It is rarely necessary to give it explicitly (but sometimes you do when the compiler cannot infer the return type on its own—thusfar in my own rust coding I’ve needed it exactly once).
Jiff: Datetime library for Rust
211–220 of 249 posts
Re: Jiff: Datetime library for Rust
#212Earlier quoted context omitted.
> More like promoted indirectly, I think by being used widely on reference code and tutorials the programmers absorbs as a familiar and quick to write method without planning much. For references/documentation/tutorials I think the use of unwrap() and friends is a tradeoff. It (arguably) allows for more focused/self-contained examples that better showcase a particular aspect, though with the risk that a reader uses t…
> Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs" It is more about always making the error reach the function that called the method/library (lost if one of the own dependencies of this library rise the panic [UB included] crashing the program), what allows the programmer to take the decision (and not to a deep…
The thing is that that kind of design isn't an unambiguous good; there are tradeoffs involved. Writing code in that manner means every single possibly-falliable operation must return an Option/Result/etc, said result checked, and the error bubbled up or the result used as appropriate. This can be quite noisy, especially before Rust 1.13.0, where users had to make do with the try!() macro instead of the ? operator. That can have negative impacts on readability/maintainability/clarity/etc. which may arguably outweigh benefits from allowing callers to handle errors, especially if callers usually don't.
This is also "viral", in that the use of any possibly-falliable operation in the implementation would require the corresponding public API to return a Result/Option/etc., even if the intent is that a correct implementation could never fail. This makes the public API clunkier, especially if/when all possible bugs are shaken out or their absence proved one way or another.
I'm guessing this kind of tradeoff is why (most?) indexing operations in Rust return the value instead of an Option/Result/etc - perhaps the team judged that most of the time users have some other way of guaranteeing success (e.g., checking indices) so panicking on failure better fits/streamlines the needs/use cases of most users rather than forcing them to constantly deal with an Option/Result/etc., especially since get()/etc. exists for those users who do want an infalliable option.
Presumably the author(s) of the library/libraries you're using made a similar judgement - while it's possible to write code in the way you desire, perhaps it just wasn't worth the bother for them and/or most of their users.
Re: Jiff: Datetime library for Rust
#213Earlier quoted context omitted.
The feature is controversial enough that it's basically a wontfix.
Is it really, though? I didn't read all the comments, but the ones I read, very few were opposing the concept as such: https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... However, many were opposing overloading the same pre-rfc was suggesting.
https://github.com/rust-lang/rfcs/issues/323 is the oldest currently open tracking issue, as you can see it has 397 comments. And that thread you linked has 171. Basically, tons of people that feel basically every possible way.
I also feel at this point it's basically a wontfix, but that's more because it's both controversial and huge, and arguably not as high of a priority as other things even if it weren't those two things. The reason it gets huge is that you really want to consider all three of {optional, named, variadric} at roughly the same time.
I do think that people are generally more supportive of variadric than optional/named.
Re: Jiff: Datetime library for Rust
#214Earlier quoted context omitted.
Adding support for struct default field values would allow for - leaving some mandatory fields - reduce the need for the builder pattern - enable the above to be written as f(S { hours: 2, seconds: 53, .. }) If that feature ever lands, coupled with structural/anonymous structs or struct literal inference, you're getting everything you'd want from named arguments without any of the foot guns.
Has anyone ever proposed it? It's such a straightforward feature with such obvious semantics ("default field values are const contexts") and impossible-to-bikeshed syntax (`a: i32 = 42`) that I've been meaning to write up an RFC myself for around, oh, ten years now...
nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806
It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...
Re: Jiff: Datetime library for Rust
#215I really think Rust should adopt one of the popular datetime crates into the std lib - it's not reasonable to offload researching maintainer status and quality to each developer needing to use dates correctly.
Rust’s stdlib is intentionally minuscule so that breaking changes can be made to important crates. Once a crate becomes part of Rust, no breaking change can ever be made to it, which is a pretty high risk situation (if chrono had been added, jiff would not be able to). Better would be for Rust to simply fund development of critical crates and let the marketplace work out which crates those are.
I think that Rust's tiny stdlib is one of the most glaring flaws of the language. I don't think that there's actually any significant upside, because people can always just use a crate if they want. On the other hand, there's significant downside because not everyone has the ability to install crates. The stdlib is the one thing that is guaranteed to be present, and it should have the most commonly used features developers will need.
Re: Jiff: Datetime library for Rust
#216Earlier quoted context omitted.
Not at all. If this library was GPL, any software using it also needs to be GPL. This means all code needs to be open source, which severely limits freedom of makers of end-user software. And almost the whole Rust ecosystem is MIT.
> which severely limits freedom of makers of end-user software And thereby severely guarantees the freedom of said end-users. The freedom to deny the freedom of another person is not a freedom worth discussing. The author expressly dislikes copyright. GPL is still the only real cure to copyright. "Permissive" licences are corporate friendly. They allow corporations to take what they want and give back nothing. In thi…
> The freedom to deny the freedom of another person is not a freedom worth discussing.
Nobody denies anyone anything. If $corp never makes a piece of software, the users never had rights to begin with. If $corp makes it but doesn't open source the software, the users still never had rights to begin with. It is not "denying people freedom" to exercise one's right to make software which is not open source.
> They allow corporations to take what they want and give back nothing.
This is, and has always been, a very weak argument. When a developer makes a public gift of their software, it is very churlish indeed to complain when someone makes use of that gift. It's also pretty hypocritical, unless you're going to make the same complaint about individuals using open source software and not giving back.
Re: Jiff: Datetime library for Rust
#217Earlier quoted context omitted.
Time library can be simple, it's just rust libraries tend to be philosophic for some reason, but it's only one of many design approaches.
They can certainly be simple and incomplete, or simple and incorrect; do you have an example of a simple, complete, and correct time library?
You think your philosophy is stronger than any other philosophy? I mean it's philosophic design approach itself which is doubtful. Correctness is satisfaction of expectations. For any library there are expectations that it doesn't satisfy.
Re: Jiff: Datetime library for Rust
#218Earlier quoted context omitted.
> unncessary artificial complexities The very fact they are there, still used, and so on, contradicts "unnessary [sic]". Sure, it might be outdated now, or technically better alternatives might be there. But, in the end, software that deals with "The Real World" is going to be a complex, illogical mess. Because the real world is a complex, illogical mess. We could make a time that is global, counts resonant frequency…
And we're going to say "let's do this a day from now", leaving the software to decide whether that's 24, 23 or 25 hours from now. It could be any of those things, depending on where it was said and the DST changes for that timezone. Or conversely, is a specified instant considered "tomorrow"?
I generally consider "tomorrow" to be an interval and not an instant. It is ambigous how large of an interval it is and how far in the future it begins.
Re: Jiff: Datetime library for Rust
#219Earlier quoted context omitted.
It's done in bad faith. Some are vehemently against Rust because of the "culture" around criticizing other languages' memory safety models, namely C/C++.
You may be right.
It is not the case, not bad faith intended. To think it is a protest may be nearer.
Build in release a hello world, Build in release the example of this library (replacing the assert_eq by a println!("{}", zoned) or other ), or even a different library if it have a large dependence tree. Open on a text editor both files. The presence of the string messages for "unwrap" increased, right?
One can observe the code in this library take care of making reach the user the errors in most the parts of the library, so:
how was increased the string messages for "unwrap"? How can one know from were they came from? One ends up having to read all the dependencies^5, from were almost always a unwrap() reach the runtime of the release build.
Re: Jiff: Datetime library for Rust
#220Earlier quoted context omitted.
Java had a pretty comprehensive rewrite of it's own time handling library and it was much needed. Time is hard because time zones are not engineering they are political and arbitrary. So yeah keeping things in Unix time is great if all your doing is reading back timestamps for when an event occurred, but the moment you have to schedule things for humans, everything is on fire.
Didn't they just incorporate JodaTime? I thought the changes were even made by the JodaTime developer.
Not exactly. It was heavily inspired by Joda Time, but it also improved the design in a lot of ways. You could think of it as Joda Time if the designer could go back in time and design it again with all the hindsight.