Make all new symbols go through std.experimental?

[James Hofmann via Digitalmars-d]

On Wednesday, 28 October 2015 at 00:28:51 UTC, Andrei 
Alexandrescu wrote:
> What say you?
>
> Andrei

I think most people like the idea of having new things 
categorized, but encounter difficulty agreeing on what categories 
to use. Everyone will make broad assumptions that fit their 
comfort zone. Word choices like "experimental" or "testing" could 
influence people's impressions of stability, and so could the 
method of friction that is added to prevent accidental use. The 
point is to be a little bit scary - but are we scaring off the 
right people when we use these words and techniques?

I don't have much D history but I would approach the issue 
ground-up and reconsider the options for introductions. I thought 
of these ways that friction could be added(considering here both 
library and language features):

1. Rebuild compiler with additional flags.
2. Available only in one or more separate library versions(e.g. a 
dub package that replaces "stable" std).
3. Run compiler with additional flags.
4. Import a named package like std.experimental.

There is a very key difference between the first three and the 
fourth in that if you have modified the compiler, your build 
flags, or your library environment, you are more likely to be 
working on a personal machine with personal projects, and can 
afford to tinker with a rapidly changing situation. With 4, 
people will be able to use it injudiciously in production by 
copy-pasting source code from someone's example - no warnings 
will appear as a result of this.

Knowing that, we have to ask some questions about workflows to 
settle what the role of std.experimental is. Friction appears 
_after_ a symbol is moved out of experimental, as noted by 
previous replies, when what is desired is for graduation out of 
experimental to be apparently seamless. On the other hand, it's 
very troublesome to have working code break after toggling a flag 
to turn on the experimental things. Flags should feel "precise" 
and not disturb the existing code. Environmental changes add 
friction around initial use - when code doesn't "just work" 
because it requires an environment change it is likely to be 
reconsidered by its user.

Perhaps that means a rule like: if it's entirely new, use a build 
flag, or expose it in an "unstable" library version. If it 
modifies/refines an old, stable symbol, use std.experimental, and 
deprecate the old API as confidence grows - thus encouraging 
people to move towards experimental often, but to start 
manipulating the rest of the environment if they want to be truly 
adventurous. (this doesn't exactly solve the "post-hoc friction" 
problem, but it scores well on accident prevention)

There's probably much more to consider but I will leave my 
thought there.