On Tue, Apr 2, 2024 at 9:27 AM Vinnie Falco
On Tue, Apr 2, 2024 at 8:58 AM Jeff Garland via Boost < boost@lists.boost.org> wrote:
I'll just note that BLAS is 'already done' in c++26 ... Like special math functions, many applications won't need these tools, but if you do it's super handy not to have to wrap some other library or Fortran itself.
I think the bar for inclusion in the standard library needs to be higher than "super handy." Everything added to the standard creates an added and perpetually recurring cost, because subsequent features need to harmonise with a growing set of already existing facilities.
Well that would require the standard to be self consistent, which it is not. Just to pick one that was brought up earlier - charconv is wildly inconsistent with (until recently) to_string and some other std apis. It's also a terrible api that *always* has to be wrapped in my projects. Thing is, it's indeed the best facility for doing conversions because of its performance based on modern algorithms. Anyway, I disagree that there's some 'massive cost' with having something in the standard -- that said I agree that my preference is to see things that all c++ users need everyday get priority.
In the past and now more recently I have heard "you can already get networking as an external library." One could say the same for this BLAS. Why does the C++ Standard now have BLAS and yet still cannot connect to the Internet, with no capability to do so coming anytime soon?
In the end, it has BLAS because a group of people were willing to put in the time needed to get the facility standardized and there's not really any disagreement about the approach. Networking, unfortunately, isn't in the same boat.
Unlike BLAS, which has little to no second order effects (that is, new libraries whose interfaces are built on this std facility) networking is the opposite. C++ desperately needs a standard networking facility, as users are currently deprived of the rich ecosystem of external, derivative network libraries that are common in other languages.
Too often the justification for library-only features in the standard comes down to one or both of:
1. this is "useful" 2. avoid the need for package managers
These discussions of convenience and utility never consider the opportunity cost. That is, what we are sacrificing in order to have these things, likely because a true cost-benefit analysis would make papers more difficult to push through. There is never much in terms of quantitative analysis. How many people would benefit, and compared to the alternative (which is always simply to download and use a third party library).
Well, these things are explicitly discussed -- but that doesn't mean that
there will be agreement -- or that Vinnie (or Jeff's) priorities will be the ones chosen. Even how to do quantitative analysis becomes a point of discussion -- as it should. For example, just bc there's a thousand github repos that implement something doesn't mean it's popular -- that could just be the standard college challenge. And finally, you have to have people willing to make unreasonable time sacrifices to get anything substantial into the standard -- even if we all want it there. Jeff