Date: Sat, 23 Sep 2023 14:24:53 -0400
On Sat, Sep 23, 2023 at 2:13 PM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>> The thing is, it's done. The feature has existed for 3 years now.
>> You're arguing for why it needs to be changed. None of what you've
>> argued for is enough reason to change things as they are. Maybe your
>> arguments might have been convincing before it was standardized, but
>> now that this has been done, you need a *compelling* reason to have it
>> changed.
>
> Compelling: Give the operator a solid definition in general terms, and let applications specialize.
This is what we have now. There is nothing non-"solid" about the status quo.
> The semantics carried by the present return type are an architectural assumption because they introduce the need, implicit or otherwise, to deal with a specific role played where it was demonstrably not needed beforehand.
How do you define "needed" compared to "nobody wanted to try it"? The
information was present, merely hidden in implicit assumptions of the
implementation.
The fact that you can get away without something doesn't mean you *should*.
> Ordering semantics are a concern for containers, not the types they hold, and can be provably unified as specific treatments of a total order.
>
> At the very least, let new code just return an int. In the case a signed difference is defined, authors don't have to assume switching over and returning symbols in std would optimize as expected.
Is there some actual performance problem with the status quo? Not a
"well, we have to assume compilers are smart," but some actual
circumstance where using an integer would genuinely offer superior
performance?
> In general: Architecture is disrupted when an unwanted or incompatible role is introduced or required by a dependency. All C++ applications are now dependent on the standard library (though I believe this can be reversed without disrupting existing code). Despite the name, not all standard libraries are created equally, and probably never will be. It must be possible to effectively use the language without the library.
Well, you and the C++ committee are going to have to agree to disagree
on that point, because that is *not* the direction the language is
going in. If the entire basis for your "compelling" justification for
your desired change is "we should back-track a bunch of features
because I don't think the language should ever depend on the library",
then that's not going to convince many people on the committee.
<std-proposals_at_[hidden]> wrote:
>> The thing is, it's done. The feature has existed for 3 years now.
>> You're arguing for why it needs to be changed. None of what you've
>> argued for is enough reason to change things as they are. Maybe your
>> arguments might have been convincing before it was standardized, but
>> now that this has been done, you need a *compelling* reason to have it
>> changed.
>
> Compelling: Give the operator a solid definition in general terms, and let applications specialize.
This is what we have now. There is nothing non-"solid" about the status quo.
> The semantics carried by the present return type are an architectural assumption because they introduce the need, implicit or otherwise, to deal with a specific role played where it was demonstrably not needed beforehand.
How do you define "needed" compared to "nobody wanted to try it"? The
information was present, merely hidden in implicit assumptions of the
implementation.
The fact that you can get away without something doesn't mean you *should*.
> Ordering semantics are a concern for containers, not the types they hold, and can be provably unified as specific treatments of a total order.
>
> At the very least, let new code just return an int. In the case a signed difference is defined, authors don't have to assume switching over and returning symbols in std would optimize as expected.
Is there some actual performance problem with the status quo? Not a
"well, we have to assume compilers are smart," but some actual
circumstance where using an integer would genuinely offer superior
performance?
> In general: Architecture is disrupted when an unwanted or incompatible role is introduced or required by a dependency. All C++ applications are now dependent on the standard library (though I believe this can be reversed without disrupting existing code). Despite the name, not all standard libraries are created equally, and probably never will be. It must be possible to effectively use the language without the library.
Well, you and the C++ committee are going to have to agree to disagree
on that point, because that is *not* the direction the language is
going in. If the entire basis for your "compelling" justification for
your desired change is "we should back-track a bunch of features
because I don't think the language should ever depend on the library",
then that's not going to convince many people on the committee.
Received on 2023-09-23 18:25:05