Date: Sat, 23 Sep 2023 12:23:57 -0400
On Sat, Sep 23, 2023 at 12:01 PM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I'm already dealing with initializer_list<> refining another idea (it seems to work, though). IMO, the philosophy for new language features ought to be to avoid making more things like typeid().
>
> I shouldn't have to #include something to use a language feature.
You can feel that way all you like, but that's not how the language
works. Or ever worked. And as we start getting things like reflection,
it's only going to get *less* viable.
The language and its library are defined by one document for a reason.
> Moreover, every compare ever written beforehand returned an 'int'. The idea that the return type needed to carry more semantic information could have been realized by allowing different return types in special cases.
The fact that people have done it a certain way in the past is not a
valid justification for changing the way we do it now. And why
wouldn't you *want* to always carry that semantic information? A
semantic-less type is inherently inferior because it is lacking
information that is rather important.
> The opening claim is easy to observe, all things we understand are actually different images of integers. The return type really ought to have been as simple as possible in the first place. The "sign of the difference" definition could give it a simple, but complete justification, doing away with "but, int is old-timey" - the answer is, did we really need a semantically-laden type for a ternary?
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.
Personal preference for a "simple" version is not particularly
compelling. You need something that is functionally impossible or some
performance issue or something of that nature.
<std-proposals_at_[hidden]> wrote:
>
> I'm already dealing with initializer_list<> refining another idea (it seems to work, though). IMO, the philosophy for new language features ought to be to avoid making more things like typeid().
>
> I shouldn't have to #include something to use a language feature.
You can feel that way all you like, but that's not how the language
works. Or ever worked. And as we start getting things like reflection,
it's only going to get *less* viable.
The language and its library are defined by one document for a reason.
> Moreover, every compare ever written beforehand returned an 'int'. The idea that the return type needed to carry more semantic information could have been realized by allowing different return types in special cases.
The fact that people have done it a certain way in the past is not a
valid justification for changing the way we do it now. And why
wouldn't you *want* to always carry that semantic information? A
semantic-less type is inherently inferior because it is lacking
information that is rather important.
> The opening claim is easy to observe, all things we understand are actually different images of integers. The return type really ought to have been as simple as possible in the first place. The "sign of the difference" definition could give it a simple, but complete justification, doing away with "but, int is old-timey" - the answer is, did we really need a semantically-laden type for a ternary?
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.
Personal preference for a "simple" version is not particularly
compelling. You need something that is functionally impossible or some
performance issue or something of that nature.
Received on 2023-09-23 16:24:09