Re: Technical Excellence?

From: Jeff Garland (azswdude_at_[hidden])
Date: 2024-04-02 16:51:14

On Tue, Apr 2, 2024 at 9:27 AM Vinnie Falco <vinnie.falco_at_[hidden]> wrote:

> On Tue, Apr 2, 2024 at 8:58 AM Jeff Garland via Boost <
> boost_at_[hidden]> 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