Time to move std.experimental.checkedint to std.checkedint ?

[Q. Schroll]

On Wednesday, 24 March 2021 at 11:20:52 UTC, Berni44 wrote:
> On Tuesday, 23 March 2021 at 21:22:18 UTC, Walter Bright wrote:
>> It's been there long enough.
>
> Isn't that true meanwhile for everything in std.experimental? I 
> ask, because I've got the feeling, that std.experimental 
> doesn't work as expected. For me it looks more or less like an 
> attic, where stuff is put and then forgotten. Maybe the way we 
> used for sumtype is the better approach...

I have no idea why std.experimental is a thing to begin with. It 
sounds like a bad idea and it turned out to be one. Moving stuff 
around in a standard library isn't without some disadvantages: 
The public import stays as an historic artifact or deprecation is 
needed, both things that should be avoided. There are cases where 
it's fine like splitting a module into a package.

A standard library is something expected to be particularly well 
done and stable. Having experimental stuff in it, is an oxymoron.

DUB packages that are "featured" is a way better approach. If 
deemed worth it (like sumtype), they can be incorporated into 
Phobos. We may even introduce a "Phobos candidate" tag. 
Additionally, that establishes DUB as a core part of the D 
ecosystem.

Can std.experimental packages be removed without deprecation?

The worst offender is std.experimental.typecons; while I don't 
really understand the purpose of (un-)wrap, I know enough of 
Final to be sure it's the kind of thing that must be a language 
feature or it cannot possibly live up to users' expectations. 
Final cannot work properly as a library solution. (I can 
elaborate if needed.) I tried fixing it until I realized it's 
impossible because it's design goal is unsound. I honestly cannot 
imagine anyone who uses it. It is cumbersome and has zero 
advantages.