Were the confusion caused by the choice of project name `pcz` instead of `xxxstd`? or any suggestion for us to improve?
This comment is the first time I realised it was not intended to be a drop-in replacement for the Go standard library (in a musl - glibc kind of relationship).
We decided to make it this way so:
1) you can import packages from the pcz std module like you do with any other Go package without setting `GOROOT` to an unofficial std.
2) and because of 1), you can import packages from pcz std in your go application but still using the `go` command rather the `pcz` command.
In the future, we may provide drop-in replacement for applications using official std by introducing a compatibility module and a cli flag to redirect imports using packages from the official std to that module.
But there was e.g. https://github.com/eloraiby/alt-std for rust, and for D there's a couple listed here - https://wiki.dlang.org/Alternative_Standard_Libraries
So if you're coming at it thinking in those terms, it's 'obviously' the right term to use to describe it.
Note that (a) I wasn't confused at all (b) it makes complete sense people -are- confused by it, and you're not at all wrong.
But, you can't make such types in your own Rust. If you wish you had NonSixU8, a type which can't be six, the only way to make it would be to base it on NonZeroU8 and use some sort of XOR scheme. The standard library is blessed with the ability to do this even though it's not available to mortals and that blessing is only open in practice to the actual standard library for the entirely practical reason that only they can co-ordinate with the compiler team to ensure it happens - if the Rust compiler re-defines how niches work the library team have to change NonZeroU8 at the same time.
So while the actual stdlibs get to do magic, which makes them stand out from a popular third party library like SDL or zlib, these "alternatives" don't.
If they provide all the same stuff as the "real" standard library that makes sense, but when they instead provide different stuff and they can't do magic I don't see any difference from any other library. Is SDL an "alternate stdlib" if we and some friends all use it all the time?
Those are unstable, so you have to use another attribute opt in to using them. But you can absolutely put them on your own type.
There's nearly nothing in the Rust stdlib you can't write yourself. OIf I recall correctly one example is the function Box::new which constructs a heap allocated smart pointer to it's argument. It "magically" skips allocating the argument on the stack of the caller in some situations.
They are, as their name suggests, deliberately perma-unstable rust compiler (rustc) only. You technically can use them in types anyway (and if you go look at the nook crate, I have, that's why I know so much about them) but because they're perma-unstable that's a terrible idea and you clearly shouldn't use this.
Even if they were just unstable, (like say const traits) you can only do this in nightly Rust, it's not available in stable Rust and as the people who'd decided "Oh, const traits, those sound great, I'll just use them and eventually they'll be stable" discovered, nope, that's not what we meant when we told you they're not stable. We meant what we said, and those traits just plain went away (probably they'll be back eventually, but maybe not).
But I agree the stuff that's "just" unstable isn't compiler magic, after all the intent is, even if it doesn't always work out, that those features eventually get stabilized. These are perma-unstable because they're compiler internals. They are magic.