Date: Mon, 25 Sep 2023 00:14:16 +0300
On Sun, 24 Sept 2023 at 23:57, Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>In cases where the meaning of the return value means more than just "undefined", and the code still assumes the semantics of "Relation", it wasn't written to deal with the failure anyway (generally, just capture the original int and propagate an error/throw an exception).
Yes, bingo. That's the point. The three-way comparisons don't return
an int because they tell you that you shouldn't just accidentally
return them onwards
as ints without thinking about what you're doing. And your code using
three-way comparisons is then less likely to just do the wrong thing
because it
would happily get an int and could think it can process it further
even though the results are already balderdash, like they are for
NaNs.
I get that you would like to have a different model, and still be able
to invoke that model with an operator<=>, but allowing that means
that three-way comparison loses the semantics of the conceptual
framework that it has, and becomes just a random DSL that can mean
whatever the user says it means. Which was one of the major problems
of earlier attempts at a "model" with operator< etc., they were and
are abused to create something completely different from comparison
operators. Three-way comparison was designed to avoid the allure
of creating a free-form DSL, and attempts to keep the conceptual
framework intact, so that the syntax doesn't have an open-ended set
of semantic meanings.
The benefits of that are ostensibly greater than the benefits of the
free-form DSL would be, especially considering the downsides of that
free-form DSL. The dislike of using library headers is a complete
non-issue, you're going to be doing 'import std;' anyway.
If you have a dislike against using the standard library at all, too
bad, you'll need at least a freestanding one to opt into this
framework, and that's just going to be that.
The rationale for being able to write programs without any sort of
support library at all are too unconvincing to make drastic conceptual
changes,
as my technical educated guesstimate on this.
<std-proposals_at_[hidden]> wrote:
>In cases where the meaning of the return value means more than just "undefined", and the code still assumes the semantics of "Relation", it wasn't written to deal with the failure anyway (generally, just capture the original int and propagate an error/throw an exception).
Yes, bingo. That's the point. The three-way comparisons don't return
an int because they tell you that you shouldn't just accidentally
return them onwards
as ints without thinking about what you're doing. And your code using
three-way comparisons is then less likely to just do the wrong thing
because it
would happily get an int and could think it can process it further
even though the results are already balderdash, like they are for
NaNs.
I get that you would like to have a different model, and still be able
to invoke that model with an operator<=>, but allowing that means
that three-way comparison loses the semantics of the conceptual
framework that it has, and becomes just a random DSL that can mean
whatever the user says it means. Which was one of the major problems
of earlier attempts at a "model" with operator< etc., they were and
are abused to create something completely different from comparison
operators. Three-way comparison was designed to avoid the allure
of creating a free-form DSL, and attempts to keep the conceptual
framework intact, so that the syntax doesn't have an open-ended set
of semantic meanings.
The benefits of that are ostensibly greater than the benefits of the
free-form DSL would be, especially considering the downsides of that
free-form DSL. The dislike of using library headers is a complete
non-issue, you're going to be doing 'import std;' anyway.
If you have a dislike against using the standard library at all, too
bad, you'll need at least a freestanding one to opt into this
framework, and that's just going to be that.
The rationale for being able to write programs without any sort of
support library at all are too unconvincing to make drastic conceptual
changes,
as my technical educated guesstimate on this.
Received on 2023-09-24 21:14:30