Re: [scope] Scope review starts on November 26th

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-12-02 10:40:13

On 11/28/23 19:14, Jeff Garland via Boost wrote:
> On Sun, Nov 26, 2023 at 7:14 AM Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
> 
>> On 11/26/23 06:27, Vinnie Falco wrote:
>>> On Sat, Nov 25, 2023 at 6:17 PM Andrey Semashev via Boost
>>> <boost_at_[hidden]> wrote:
>>
>>>> The fact that the standard doesn't provide that functionality (provided
>> that it is needed by users) is a deficiency of the standard, not the Boost
>> library.
>>>
>>> Users vastly prefer even the "defective" std components over the
>>> theoretically-better boost components, simply by virtue of them being
>>> in the standard, with all of the benefits this brings. Education,
>>> documentation, ubiquity, and so on, for std components is orders of
>>> magnitude more robust than the boost equivalent. This more than makes
>>> up for any perceived deficiencies. Like it or not, vocabulary types
>>> and algorithms which make it into std are going to have an enormous
>>> advantage over any third party code.
>>
>> I'd like to think everyone is free to make their own choice based on
>> their own criteria and merits of each of the options. Availability of
>> the standard library is an important advantage, but it is not ultimate.
>> Personally, I find the standard library severely lacking, meaning I
>> cannot reasonably write a serious project relying solely on the standard
>> library and nothing else. I'd have to write a lot of code that I know
>> exists and tested in other libraries like Boost, and I'd have to be mad
>> not to try and reuse it. So you could say Boost is my natural extension
>> of the standard library, something that I always have by my hand, just
>> as easily reachable as the standard library.
>>
>> BTW, on the topic of innovation and stagnation, my other complaint about
>> the standard library (or rather its implementations, every one of them)
>> is that once a feature is implemented, it gets frozen because of ABI
>> stability. Stable ABI is important, but because of it bugs like this[1]
>> never get fixed.
>>
>> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
>>
>>
> I don't disagree with your overall point (see my comment on opt-in), but
> it's simply untrue that things are *frozen* -- implying no changes are
> possible due to ABI constraints.  Newer versions of optional support
> additional facilities (monadic interface) and I suspect you'll see support
> for references in 26.  Yep, ABI updates prevent some changes, but not every
> change.

Adding new features is relatively easy. But once they are added, they
become effectively frozen.