Core: Mutual conversion operators to constructors #95288
+68
−56
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Repiteo
force-pushed
the
core/math-operator-to-constructor
branch
from
294e446 to
abaae19
Compare
Repiteo
force-pushed
the
core/math-operator-to-constructor
branch
from
abaae19 to
73a13ff
Compare
akien-mga
reviewed
Nov 12, 2024
Comment on lines
+375
to
+382
| #ifdef RECT2I_H | ||
| Rect2::Rect2(const Rect2i &p_rect) : | ||
| position(p_rect.position), | ||
| size(p_rect.size) {} | ||
| Rect2i::Rect2i(const Rect2 &p_rect) : | ||
| position(p_rect.position), | ||
| size(p_rect.size) {} | ||
| #endif // RECT2I_H |
There was a problem hiding this comment.
I guess this wouldn't play nice with #pragma once.
I don't fully understand how this works but it seems to make things quite dependent of include order?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While brainstorming ways to make the math struct types play nicely with each other in a
constexprenvironment, I eventually came across a C++ quirk I wasn't previously aware of: a function with a forward-declared type can itself be forward declared, and only needs to be properly defined if the type itself is resolved. With this in mind, any float-to-int conversions in math structs are able to not only utilize constructors instead of conversion operators, but are able to be safely defined in aconstexprcontext!While this isn't a
constexprPR (see #92059), this does open the door for allowing proper interopability between structs defined in entirely separate headers. As for immediate benefits, this slightly simplifies logic by not needing both a constructor and conversion operator, as the former effectively replaces the latter.