> but the datetime APIs refuse to expose leap-second info because they're too committed to "only UTC is in-scope for this project".
This doesn't make sense on at least two different levels.
First, pedantically, the definition of UTC as a time scale is that it includes leap seconds. So if you're committed to UTC, then you're supporting leap seconds.
Second, and to more broadly address your point, you should say, "they're too committed to 'only the POSIX time scale is in-scope for this project.'" That more accurately captures the status quo and also intimates the problem: aside from specialty applications, basically everything is built on POSIX time, which specifically ignores the existence of leap seconds.
Sure, but my gripe isn't even that we ought to change the "POSIX time by default" status quo (the ship has long sailed that everyone counts durations by 'calendar seconds'), it's that the underlying libraries don't even provide enough information for "specialty applications" to reliably correct for it, short of perpetually updating it themselves.
Why should they though? To me it seems like a niche of a niche. I think there is plenty of room for scientific datetime libraries to service this need in a way that is likely better than what a general purpose datetime library would provide. (And indeed, there are many of them.)
I say this as someone who had leap second support working in a pre-release version of Jiff[1] (including reading from leapsecond tzdb data) but ripped it out for reasons.[2]
It’s not “niche” if you do things synchronized to GPS timestamps. (i.e. a significant portion of telecom, a bunch of electrical grid stuff, etc).
Anything using GPS as lock references to synchronize stuff that needs to be aligned to the millisecond absolutely cannot tolerate stuff like “the leap second smear”.
The vast majority of people using date time libraries don’t need to represent dates before 1980 or dates after 2036. It doesn’t mean you just bury your head in the sand and ignore a pretty critical part of how time representation works.
That's part of it: If I were writing a standalone program that could extract info from tzdb or whatever, I'd happily jump through those hoops, and not bother anyone else's libraries. I don't really care about the ergonomics. But for JS scripts in particular, there is no information available that is not provided by either the browser APIs or someone's server. And such servers are not in great supply.
Nice. Yeah I'd have to actually look at what it did. For the task of substring search, it's extremely easy to fall into a local optima. The `memchr` crate has oodles of benchmarks, and some of them are very much in tension with others. It's easy to do well on one to the expense of others.
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
I suppose it's possible. I wonder if I'll become a better driver if I take off my seatbelt. Or even better, if I take my son out of my car seat and just let him roam free in the back seat. I'm sure my wife will buy this.
Human behaviour can be a confounding thing. There was some debate a while ago [1] about whether bike helmet use may actually lead more head injuries due to factors like drivers passing closer to helmeted riders vs. unhelmeted ones or riders riding more recklessly, among a tonne of other factors. I still prefer to wear a helmet, but its an interesting example of how difficult it can be to engineer human behaviour.
Another good example of this is how civil engineers adding safety factors into design of roads - lane widths, straighter curves, and so on - leading drivers to speed more and decreasing road safety overall.
FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
But in this specific case, if the respawn feature is not available or dying isn't a desirable event, FAFO might not be the best way to learn how to drive.
I also think we have the data in for memory safety in C. Even the best people, with the best processes in the world seem to keep writing memory safety bugs. The “just be more vigilant” plan doesn’t seem to work.
> FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
Yes, just sucks for the person who you hit with your car, or the person whose laptop gets owned because of your code.
"FAFO" is not a great method of learning when the cost is externalized.
Not necessarily at all. Go peruse the `regex` crate source code, including its dependencies.
The biggest `unsafe` sections are probably for SIMD accelerated search. There's no "unnatural abstractions" there. Just a memmem-like interface.
There's some `unsafe` for eliding bounds checks in the main DFA search loops. No unnatural abstractions there either.
There's also some `unsafe` for some synchronization primitives for managing mutable scratch space to use during a search. A C library (e.g., PCRE2) makes the caller handle this. The `regex` crate does it for you. But not for unnatural reasons. To make using regexes simpler. There are lower level APIs that provide the control of C if you need it.
That's pretty much it. All told, this is a teeny tiny fraction of the code in the `regex` crate (and all of its dependencies).
That can be tricky because there may be a trade-off between error message quality and something else. Like, perhaps, the size of an error, code size or even runtime performance. Another trade-off with too-detailed errors---especially when those details are part of the library API---is that they become an extensibility hazard. Unless you're extremely certain about the line that divides a specific implementation from the logical domain of errors for a particular operation, you might get that wrong. And changing the implementation in the future might want a change in the error details.
This is very hand-wavy, but I think we're talking at a very high level of abstraction here. My main point is to suggest that there is more of a balancing act here than perhaps your words suggest.
I agree that it's a balancing act. I just don't think you get to abdicate from doing that balancing act and getting the balance wrong has consequences just like getting the balancing act wrong in your non error data model.
> It was `std` only and linked to a concept of backtraces, which made it a non-started for embedded. It just seemed to me that it was a bad idea ever to use it in a library and that it would harm embedded users.
It was never linked to backtraces. And if you used `std::error::Error` in a library that you also wanted to support in no-std mode, then you just didn't implement the `std::error::Error` trait when the `std` feature for that library isn't enabled. Nowadays, you can just implement the `core::error::Error` trait unconditionally.
As for backtrace functionality, that is on the cusp of being stabilized via a generic interface that allows `core::error::Error` to be defined in `core`: https://github.com/rust-lang/rust/issues/99301
> and it to this day has no built-in idea of "error accumulation".
The `Error` trait has always had this. It started with `Error::cause`. That was deprecated long ago because of an API bug and replaced with `Error::source`.
> It just felt like too much churn and each one offered barely any distinction to the previous.
That blog did include a recommendation for `failure` at one point, and now `anyhow`, but it's more of a footnote. The blog shows how to do error handling without any dependencies at all. You didn't have to jump on the error library treadmill. (Although I will say that `anyhow` and `thiserror` have been around for a number of years now and shows no signs of going away.)
> I don't bother with implementing `std::error::Error`, because it's pointless.
It's not. `std::error::Error` is what lets you provide an error chain. And soon it will be what you can extract a backtrace from.
> I'm kind of in the downcasting-is-a-code-smell camp anyways.
> I wrote about how to do error handling without libraries literally the day Rust 1.0 was published: https://burntsushi.net/rust-error-handling/
>
> That blog did include a recommendation for `failure` at one point, and now `anyhow`, but it's more of a footnote. The blog shows how to do error handling without any dependencies at all. You didn't have to jump on the error library treadmill. (Although I will say that `anyhow` and `thiserror` have been around for a number of years now and shows no signs of going away.)
Thank you -- I just wanna say, I read a lot of your writing and I love your work. I'm not sure if I read that blog post so many years ago but it looks like a good overview that has aged well.
I still think the error chain abstraction should actually be a tree.
And I think they should never have stabilized an `std::error::Error` trait that was not in core. I think that itself was a mistake. And 8 years later we're only now maybe able to get there.
I actually said something on a github issue about this before rust 1.0 stabilization, and that it would cause an ecosystem split with embedded, and that this really should be fixed, but my comment was not well received, and obviously didn't have much impact. I'll see if I can find it, it's on github and I remember withoutboats responded to me.
Realistically the core team was under a lot of pressure to ship 1.0 and rust has been pretty successful -- I'm still using it for example, and a lot of embedded folks. But I do think I was right that it caused an ecosystem split with embedded and could have been avoided. And the benefit of shipping a janky version of `std::error::Error` however many years ago, almost all of which got deprecated, seems hard to put a finger on.
To clarify, I'm on libs-api. I've been on it since the beginning. Stabilizing `std::error::Error` was absolutely the right thing to do. There were oodles of things in Rust 1.0 that weren't stable yet that embedded use cases really wanted. There are still problems here (like I/O traits only being available in `std`). The zeitgeist of the time---and one that I'm glad we had---was to ship a stable foundation on which others could build, even if there were problems.
But also, to be clear, `core::error::Error` has been a thing for over a year now.
> And the benefit of shipping a janky version of `std::error::Error` however many years ago, almost all of which got deprecated, seems hard to put a finger on.
Again, I think you are overstating things here. Two methods were deprecated. One was `Error::description`. The other was `Error::cause`. The latter has a replacement, `Error::source`, which does the same thing. And `Error::description` was mostly duplicative with the `Display` requirement. So in terms of _functionality_, nothing was lost.
Shipping in the context of "you'll never be able to make a breaking change" is very difficult. The downside with embedded use cases was known at the time, but the problems with `Error::description` and `Error::cause` were not (as far as I remember). The former was something we did because we knew it could be resolved eventually. But the APIs that are now deprecated were just mistakes. Which happens in API design. At some point, you've got to overcome the fear of getting it wrong and ship something.
I think it's true that right up until 1.0, backtrace was a part of `trait Error`, then it was deprecated and removed, but there were ongoing discussions as late as 2021 about how the "point" of `std::backtrace::Backtrace` was to attach it to an `Error`. I have lots of links and references there.
As a user, that kind of meant that as long as I thought `trait Error` might grow backtraces someday, I should stay away from it in order to be friendly to embedded. And as long as it wasn't in core, that could still happen. I hope you can agree that it was far from clear what was going to happen until relatively recently.
> At some point, you've got to overcome the fear of getting it wrong and ship something.
Also Editions mean we can go back and fix things "for the future" in some cases if that's worth the price. For example I believe it's worth the price for the built-in ranges to become IntoIterator, indeed I hoped that could happen in the 2024 edition. It was, I think we'd both agree, worth it to fix arrays in 2021.
This is one of the less celebrated but more important wins of Rust IMO because it not only unlocked relatively minor direct benefits it licensed Rust's programmers to demand improvements, knowing that small things were possible they wanted more.
Yeah, the edition thing is cool, but there's also a cost to it, which is that over time you accumulate more and more support code in the compiler for really ancient editions.
I don't have a super good understanding of how it actually works in rustc. In C++ typically they would use name mangling tricks to try to keep new and old standard library symbols from clashing if they decided to break compatibility. Probably with rustc they are happier to leave it unspecified. I have a hard time building a mental model of what kinds of things would be totally impractical to change with an edition.
For the Range types, what would happen is (AIUI) something like this (example is for Range, but several other types are affected similarly):
1. The new ranges are stabilized, they become usable from stable Rust, as well as a core::ops::Range, the half-open range type in today's Rust, you'd be able to make a core::range::Range, a modern rendition of the same idea. The new type implements Copy and IntoInterator, and provides an iter() method to iterate over immutable references, all things the old type wasn't designed to accommodate.
2. A new Rust edition says that now A..B is syntax sugar for core::range::Range { start: A, end: B } rather than the same idea but for core::ops::Range. In your existing Rust your range notations are thus still core::ops::Range, but in new Rust projects written for a new edition they are core::range::Range with the nicer semantics.
So, there's no name mangling trick, the types continue to both exist, just when you write 0..4 meaning the integers 0, 1, 2 and 3, now you mean the modern type. You may need to write a little glue for older libraries to turn your modern types into Iterators they expect, but it's trivial and soon enough all modern Rust code would behave as though the ranges had always implemented Copy and IntoIterator just as today Rust code behaves as though the arrays had nice properties which in say 2018 Edition they did not.
In terms of mental models, an Edition can change what the concrete syntax of Rust means, so often the strategy is in two parts, 1: In ordinary releases ship an awkward way to express the new idea, this is 100% compatible with existing code, but has poor ergonomics - then 2: In an Edition change the language so that the new idea is easy to express
So you can see for Ranges, that first element would be stabilizing core::range::Range (and other similar types) then the edition would change the syntax.
By error accumulation, I mean a tree of errors, not a simple chain. The chain is only useful at the very lowest level.
The tree allows you to say e.g. this function failed because n distinct preconditions failed, all of which are interesting, and might have lower level details. Or, I tried to do X which failed, and the fallback also failed. The error chain thing doesn’t capture either of these semantics properly.
Check out `rootcause` which is the first one I’ve seen to actually try to do this.
I don't see any reason for something like `rootcause` to become foundational. Most errors are a linear chain and that's good enough for most use cases.
It's correct to say that `std::error::Error` does not support a tree of errors. But it is incorrect to say what you said: that it's pointless and doesn't allow error accumulation. It's not pointless and it does provide error accumulation. Saying it doesn't is a broad overstatement when what you actually mean is something more precise, narrow and niche.
There's a semantics discussion about whether progressively adding context to errors (forming an error chain) counts as "error accumulation" or if error accumulation means collecting several errors that occurred and returning that to the caller. But at this point I think you understand what I meant and I understand your meaning.
I do think that `std::error::Error` is mostly pointless. That's a value judgment, and reasonable people can disagree.
I've tried to argue that, it can create bigger problems then it solves. It's a trait that only exists on platforms with `std`. That itself is pretty nasty and if you care at all about platforms that aren't like that, you're taking on a lot of build complexity. If you really need this why not just make your own `trait HasCause` which is like a subset of `std::error::Error` functionality, and simply doesn't require `std`?
I'll list a number of things that I've experienced coworkers being confused about around the `std::error::Error` trait.
1) Why does it require `Display` and then not use it?
2) Displaying it is very simple: `format!("{err}")`. If you want to format the error and it's chain of causes, actually using the `std::error::Error` functionality, the recommended way was to use yet another experimental `error_chain` library. When should we actually do that? When is that appropriate?
Now we have a place where there's two different ways to do the same thing (display an error). Additionally there is controversy and churn around it.
In a large project, most developers will be completely ignorant about the second more obscure possibility. And in most projects, you don't really need two ways to format an error. So I tend to do the friendliest thing for developers. There is only one way, and it is Display, which 100% of rust developers know about, and I avoid using `std::error::Error`.
I understand that there's a bright shiny future that people hope it's headed for, where everything around `std::error::Error` is easy and obvious, and we have powerful flexible expressive ergonomic error handling. I was excited about that like 7 years ago, now I just kinda want to change the channel. I'm glad some people still find some benefit in the small improvements that have occurred over time... and I hope in 8 more years there's more to the story than where we are today.
> I do think that `std::error::Error` is mostly pointless. That's a value judgment, and reasonable people can disagree.
I took it as a statement of fact. It is a factual matter of whether `std::error::Error` has a point to it or not. And it definitively does. I use the error chain in just about every CLI application I've built. It's not even mostly pointless. It's incredibly useful and it provides an interoperable point for libraries to agree upon a single error interface.
And one `Error::provide` is stable, it will be even more useful.
> I've tried to argue that, it can create bigger problems then it solves. It's a trait that only exists on platforms with `std`. That itself is pretty nasty and if you care at all about platforms that aren't like that, you're taking on a lot of build complexity. If you really need this why not just make your own `trait HasCause` which is like a subset of `std::error::Error` functionality, and simply doesn't require `std`?
The `Error` trait has been in `core` for about a year now. So you don't need any build complexity for it.
But you're also talking to someone who does take on the build complexity to make `std::error::Error` trait implementations only available on `std`. (Eventually this complexity will disappear once the MSRV of my library crates is new enough to cover `core::error::Error`.) But... there really isn't that much complexity to it? It's a very common pattern in the ecosystem and I think your words are dramatically overstating the work required here.
> 1) Why does it require `Display` and then not use it?
Because it defines the contract of what an "error" is. Part of that contract is that some kind of message can be generated. If it didn't require `Display`, then it would have to provide its own means for generating a message. It's not a matter of whether it's "used" or not. It's defining a _promise_.
> 2) Displaying it is very simple: `format!("{err}")`. If you want to format the error and it's chain of causes, actually using the `std::error::Error` functionality, the recommended way was to use yet another experimental `error_chain` library. When should we actually do that? When is that appropriate?
Who says it was "the recommended way"? I never recommended `error_chain`.
Writing the code to format the full chain is nearly trivial. I usually use `anyhow` to do that for me, but I've also written it myself when I'm not using `anyhow`.
> Now we have a place where there's two different ways to do the same thing (display an error). Additionally there is controversy and churn around it.
Yes, this is a problem. If something appears in the `Display` of your error type, then it shouldn't also appear in your `Error::source`. This is definitely a risk of getting this wrong if you're writing your error type out by hand. If you're using a library like `thiserror`, then it's much less likely.
> I understand that there's a bright shiny future that people hope it's headed for, where everything around `std::error::Error` is easy and obvious, and we have powerful flexible expressive ergonomic error handling. I was excited about that like 7 years ago, now I just kinda want to change the channel. I'm glad some people still find some benefit in the small improvements that have occurred over time... and I hope in 8 more years there's more to the story than where we are today.
I was very happy with error handling in Rust at 1.0 personally.
I think people got burned by the churn of the error library treadmill. But you didn't have to get on that treadmill. I think a lot of people did because they overstate the costs of write-once boiler plate and understate the costs of picking the wrong foundation for errors.
Let me be clear cause I think my initial post was harsher sounding than I intended.
I love working in rust. I love Result, and the ? sigil, etc. I love the enums and match, and how non_exhaustive works. I love all that.
I think that means I love rust error handling as well!
I just didn't love `std::error::Error`, it caused some pain. I think they should have just waited to stabilize until it was ready to go in core. If it wasn't there on day 1, rust error handling would have worked great! It's actually a pretty small and inessential part of the rust error handling story. I mean at this point I've hardly used it at all in 8 years using rust almost every day.
And all those churning crates, failure etc., like, that was just some people's opinions about what a fancier error framework might look like. And absolutely you're right we didn't need to get on that treadmill.
I wanted to support the OP's minimalist take though and complement it with my own though -- for a certain type of engineer that I have worked with, "use std::error::Error` looks like a "best practice" and that means that we aren't writing "good" or "idiomatic" rust if we don't use it. I do think it's a completely valid choice to eschew it. But it is somewhat harder to justify if that trait is in core now.
> I took it as a statement of fact. It is a factual matter of whether `std::error::Error` has a point to it or not. And it definitively does. I use the error chain in just about every CLI application I've built. It's not even mostly pointless. It's incredibly useful and it provides an interoperable point for libraries to agree upon a single error interface.
Okay, I'm willing to give you this one. I haven't encountered this view among coworkers before. The consensus view in my circles was, there is potentially a very small upside if your consumer is willing to do the error chain song and dance, but most people don't, and you have a risk of a lot of complexity for no_std builds, so it's better to avoid. But that may be a biased take and there may be lots of applications where the error chains are really great, and I just haven't encountered them.
> The `Error` trait has been in `core` for about a year now. So you don't need any build complexity for it.
I actually had no idea that it has been in `core for a year now!!
I am very happy, this means that the situation has actually improved dramatically and there's no major downside to using `std::error::Error`.
I'm going to re-evaluate my choices. I have a lot of code that systematically avoids `std::error::Error`, and I'm not sure it's worth it to change it all, but there's probably no good reason to avoid it if it's in core now.
---
I think you are mistaken, however, about backtraces never being a part of std::error::Error. There are RFC's from 2018 years ago that talk all about it:
It may just be a matter of perspective -- if you don't count rust pre 1.0, then yeah it "never" involved backtrace. But in my company, we were trying to use rust even at that time for no_std targets, and trying to figure out where the puck was headed on std::error::Error was complicated. All the backtrace stuff made us think, maybe this is just not meant for us and we should rip it out, and we did eventually, although not without a lot of internal arguments.
> It's incredibly useful and it provides an interoperable point for libraries to agree upon a single error interface.
>
> And one `Error::provide` is stable, it will be even more useful.
Now it's clear to you that the "point" of it is error chains, that was maybe not a consensus view of the libs team on the day of 1.0.
> We discussed this at the recent Libs meeting and came to the conclusion that stabilizing Backtrace without Error::backtrace wouldn't be a useful direction, given that Backtrace is designed around being carried alongside Errors. So for now we can consider the stabilization blocked pending figuring out the last bits of what a pluggable (whether stably or not) backtrace would look like.
>
> We can move design discussion over to #77384
Because if the only purpose was error chains, it could have been in core on the day of rust 1.0, as it is today. I think what actually happened is `fn backtrace(&self) -> Option<Backtrace>` was removed shortly before 1.0, but there were some misgivings about that and some on the core team wanted to bring that back eventually. And that was the main reason that it could not move to core, because that would make it a breaking change to bring `fn backtrace` back. At least that's what I remember from PRs I followed at the time. (There may have been other reasons besides this though?)
So, hearing that it is now actually in core is great, that resolves uncertainty I've had for like 7 years. Thank you!
> It may just be a matter of perspective -- if you don't count rust pre 1.0, then yeah it "never" involved backtrace.
Yes. I'm only counting what has been part of the stable API since Rust 1.0.
I agree that following the stabilization path and future direction of a feature can be difficult.
> Because if the only purpose was error chains, it could have been in core on the day of rust 1.0, as it is today. I think what actually happened is `fn backtrace(&self) -> Option<Backtrace>` was removed shortly before 1.0, but there were some misgivings about that and some on the core team wanted to bring that back eventually. And that was the main reason that it could not move to core, because that would make it a breaking change to bring `fn backtrace` back. At least that's what I remember from PRs I followed at the time. (There may have been other reasons besides this though?)
The only purpose is not chaining. Backtraces were definitely a desirable part of it! But we wanted to move `Error` to `core` and having backtraces be tightly coupled to `Error` would not allow that. As far as I remember, that was always the tension. To my memory, it wasn't until Jane wrote down the "generic member access" direction[1] for the `Error` trait that this tension was finally broken.
I think we should provide the building blocks (display, etc like derive_more) rather than a specialized version one for errors (thiserror).
I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.
I don't quite understand the issue about public error enums? Distinguishing variants is very useful if some causes are recoverable or - when writing webservers - could be translated into different status codes. Often both are useful, something representing internal details for logging and a public interface.
I agree. Is he really trying to say that e.g. errors for `std::fs::read()` should not distinguish between "file not found" and "permission denied"? It's quite common to want to react to those programmatically.
IMO Rust should provide something like thiserror for libraries, and also something like anyhow for applications. Maybe we can't design a perfect error library yet, but we can do waaay better than nothing. Something that covers 99% of uses would still be very useful, and there's plenty of precedent for that in the standard library.
I doubt epage is suggesting that. And note that in that case, the thing distinguishing the cause is not `std::io::Error`, but `std::io::ErrorKind`. The latter is not the error type, but something that forms a part of the I/O error type.
It's very rare that `pub enum Error { ... }` is something I'd put into the public API of a library. epage is absolutely correct that it is an extensibility hazard. But having a sub-ordinate "kind" error enum is totally fine (assuming you mark it `#[non_exhaustive]`).
It's not uncommon to have it on the error itself, rather than a details/kind auxiliary type. AWS SDK does it, nested even [0][1], diesel[2], password_hash[3].
It's not necessarily about frequency, but about extensibility. There's lot of grey area there. If you're very certain of your error domain and what kinds of details you want to offer, then the downside of a less extensible error type may never actualize. Similarly, if you're more open to more frequent semver incompatible releases, then the downside also may never actualize.
- Struct variant fields are public, limiting how you evolve the fields and types
- Struct variants need non_exhaustive
- It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type
None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.
> Struct variant fields are public, limiting how you evolve the fields and types
But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?
> Struct variants need non_exhaustive
Can't you just add that tag? I dunno, I've never actually used thiserror.
> > Struct variant fields are public, limiting how you evolve the fields and types
> But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?
Likely you should use private fields with public accessors so you can evolve it.
Having private variants and fields would be useful, yeah. Std cheats a bit with its ErrorKind::Uncategorized unstable+hidden variant to have something unmatchable.
Yes, but now you have a slice of MaybeUninit instead of T. This is totally fine for code you control, but out-parameters of the shape &mut [T] are very common for data en/decoding crates, and those require an initialized slice per Rust initialization rules, even if/though most of these will only write to out or reference elements previously written. In practice you can still reserve+set_len, but it is undefined behavior in rust for a &[T] to exist that points to uninitialized memory; at least this is my understanding. If that were not the case, then the spare_capacity_mut API would be kind of pointless?
If something is asking for `&mut [T]`, then yes, it's required that it be initialized. This is a good thing, because a `&mut [T]` permits reading that `T` in safe code, which would be UB if the `T` were uninitialized.
It seems like your complaint is more about "more APIs should accept possibly uninitialized data, but they don't." Which is fair, but I don't know how big of a deal it really is. There is for sure desire to make this work with `std::io::Read`, and indeed, there are unstable APIs for that[1].
Thanks for sharing! I hadn't seen Biff – it's way more comprehensive than what I built.
nanji was just a quick scratch-my-own-itch tool for checking "what time is it in Tokyo/Dallas right now", but I can see Biff handles that and much more.
I'll definitely look into jiff for the system tzdb approach.
This doesn't make sense on at least two different levels.
First, pedantically, the definition of UTC as a time scale is that it includes leap seconds. So if you're committed to UTC, then you're supporting leap seconds.
Second, and to more broadly address your point, you should say, "they're too committed to 'only the POSIX time scale is in-scope for this project.'" That more accurately captures the status quo and also intimates the problem: aside from specialty applications, basically everything is built on POSIX time, which specifically ignores the existence of leap seconds.
reply