What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing.
See, for example, crypto before NaCl came around.
(NB: I'm not defending either this C++ standard or random(3).)
What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing.
Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3).
Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.
See, for example, crypto before NaCl came around.
(NB: I'm not defending either this C++ standard or random(3).)