Comment by motorest
3 days ago
> Except the devil is in the details as usual, the way linalg is specified doesn't guarantee numeric stability across library implementations or compilers.
I think this criticism is silly. You're complaining about the C++ standard not enforcing something that is virtually impossible and no implementation under the sun even suggests it would conceivably support. And we should just assume C++ would be able to force it across implementations, target platforms, and even architectures? Ridiculous.
> Just like the std::random mess (...)
The comments I've seen regarding std::random mainly refer to gotchas, such as std::rand returning values in [0, RAND_MAX] and the latter being a platform-specific constant.
There is a reason after all why you only throw vague complains of "mess" instead of pointing out specific concerns or grievances. You need to complain, regardless of merit.
Overall, this blend of criticism is no different than the cliche criticism targeting the STL. Sure, some niche applications can and do have better ways to scratch their niche itches. In the meantime the STL perfectly serves the need of 99.9% of all common usages. Is this not the point? Doesn't linalg and rand achieve this?
Of course vapid nitpickers can still pull out the last resort card of complaining that the implementation is too complicated, a grievance also directed at the STL. But that's just the extent where this silliness goes.
Not silly at all, if it can't be enforced in a standard portable way, its place doesn't belong in the standard, at all.
I would have voted SA on this matter, if I had a life that would allow me to go around voting at WG21 meetings.
We have vcpkg and conan now, the standard library cannot be a distribution vehicle for organisations that refuse to adopt C++ package managers.