Date: Fri, 9 Jul 2021 11:49:29 -0500
On Fri, Jul 9, 2021 at 10:23 AM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> These tag types are not for general programming, they're for use as
> constructor arguments.
It is more than just that, as we have the full set of heterogeneous
comparisons between optional<T> and nullopt_t, as well as *smart_ptr<T,
...>* and nullptr_t. It is inconsistent that they themselves don't have a
full set of homogeneous comparisons, especially given how simple it is to
define them.
> Don't pass them
> into your hypothetical generic code and expect them to LSP to some
> other type (which type? There's an open
> set of such types.).
>
I agree that LSP has nothing to do with this.
I also agree that such a proposal would have to go to EWG as well as LEWG.
The homogenous equality comparisons for nullptr_t are defined at the
language level and not at the library level, and these would need to be as
well.
std-proposals_at_[hidden]> wrote:
> These tag types are not for general programming, they're for use as
> constructor arguments.
It is more than just that, as we have the full set of heterogeneous
comparisons between optional<T> and nullopt_t, as well as *smart_ptr<T,
...>* and nullptr_t. It is inconsistent that they themselves don't have a
full set of homogeneous comparisons, especially given how simple it is to
define them.
> Don't pass them
> into your hypothetical generic code and expect them to LSP to some
> other type (which type? There's an open
> set of such types.).
>
I agree that LSP has nothing to do with this.
I also agree that such a proposal would have to go to EWG as well as LEWG.
The homogenous equality comparisons for nullptr_t are defined at the
language level and not at the library level, and these would need to be as
well.
-- Nevin ":-)" Liber <mailto:nevin_at_[hidden] <nevin_at_[hidden]>> +1-847-691-1404
Received on 2021-07-09 11:50:13