Date: Mon, 21 Jul 2025 15:22:38 -0400
On Mon, Jul 21, 2025 at 2:31 PM Elijah Clark via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Non-Member Conversion Operator Overload
> Problem
> With implementing conversion (typecast, static_cast) operator overloading of a partial template specialization class, the conversion only applies for the primary definition not any of the partial specialization class definitions.
> I might be missing something within C++ that could solve my issue, I am also working in Visual Studio 2022, MSVC “Preview - Features from the Latest C++ Working Draft (/std:c++latest)”, so please correct me if anything is wrong. I am sorry if this has been brought up before, but I could not find anything related to the topic at discussion.
> My Project Requirements
> I am currently working on a compile-time linear algebra project. For Vectors, I need to be able to make an N-Dimensional arbitrary Vector, with the most common vectors allowing for the usual “V.x, V.y, V.z, V.w” member attributes.
> Current Solution
> Currently in present C++, you need to add a macro for (or a copy of) all the necessary conversion operator overloads. This solution is not easily maintainable for larger projects and pollutes the macro space with possibly unneeded macros. Furthermore, this solution is cumbersome and not beginner friendly as one would think of the alternative solutions presented below.
I'm guessing you need to copy/paste this code because you want users
to be able to type `.x`, `.y`, `.z`, and `.w` instead of `[0]`, `[1]`,
`[2]`, `[3]`. Concept requirements could allow you to use `.x()`, etc
without all of the copy/paste gymnastics. The function `x` would
`requires` that the size of the vector is on the range [1, 4). The `y`
function would `requires` that the vector size is `[2, 4)`, etc.
We don't need a language feature just because some people would rather
use a member variable instead of a function call.
> How would this affect existing code?
> Yes, letting the user be able to create conversion operators willy-nilly could break projects that rely on a class not converting to different types, but I feel this could benefit way more than break. Furthermore, why would a user start adding typecasting randomly in a project? And couldn’t you do this by using member conversion operator overloading?
I don't believe you have properly engaged with this issue.
At its core, your proposal means that the answer to
`std::convertible_to<U, T>` is not fixed. It's not a question you can
ask once U and T are defined as it now may depend on declarations
outside of either type's definition.
That's bad.
Implicit conversion is a property of a type, either of the source type
or the destination type. If you have definitions for both of those
types, `convertible_to` is a question that should have exactly one
answer. To be able to define a conversion operator for a type is not
all that different from being able to add to a type's constructor
overload set after defining the type.
<std-proposals_at_[hidden]> wrote:
>
> Non-Member Conversion Operator Overload
> Problem
> With implementing conversion (typecast, static_cast) operator overloading of a partial template specialization class, the conversion only applies for the primary definition not any of the partial specialization class definitions.
> I might be missing something within C++ that could solve my issue, I am also working in Visual Studio 2022, MSVC “Preview - Features from the Latest C++ Working Draft (/std:c++latest)”, so please correct me if anything is wrong. I am sorry if this has been brought up before, but I could not find anything related to the topic at discussion.
> My Project Requirements
> I am currently working on a compile-time linear algebra project. For Vectors, I need to be able to make an N-Dimensional arbitrary Vector, with the most common vectors allowing for the usual “V.x, V.y, V.z, V.w” member attributes.
> Current Solution
> Currently in present C++, you need to add a macro for (or a copy of) all the necessary conversion operator overloads. This solution is not easily maintainable for larger projects and pollutes the macro space with possibly unneeded macros. Furthermore, this solution is cumbersome and not beginner friendly as one would think of the alternative solutions presented below.
I'm guessing you need to copy/paste this code because you want users
to be able to type `.x`, `.y`, `.z`, and `.w` instead of `[0]`, `[1]`,
`[2]`, `[3]`. Concept requirements could allow you to use `.x()`, etc
without all of the copy/paste gymnastics. The function `x` would
`requires` that the size of the vector is on the range [1, 4). The `y`
function would `requires` that the vector size is `[2, 4)`, etc.
We don't need a language feature just because some people would rather
use a member variable instead of a function call.
> How would this affect existing code?
> Yes, letting the user be able to create conversion operators willy-nilly could break projects that rely on a class not converting to different types, but I feel this could benefit way more than break. Furthermore, why would a user start adding typecasting randomly in a project? And couldn’t you do this by using member conversion operator overloading?
I don't believe you have properly engaged with this issue.
At its core, your proposal means that the answer to
`std::convertible_to<U, T>` is not fixed. It's not a question you can
ask once U and T are defined as it now may depend on declarations
outside of either type's definition.
That's bad.
Implicit conversion is a property of a type, either of the source type
or the destination type. If you have definitions for both of those
types, `convertible_to` is a question that should have exactly one
answer. To be able to define a conversion operator for a type is not
all that different from being able to add to a type's constructor
overload set after defining the type.
Received on 2025-07-21 19:22:51