| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
|
||
| print: <T : type> ( msg: std::string, x: T ) | ||
| requires !std::convertible_to<T, bool> = | ||
| non_bool: <T> concept = !std::convertible_to<T, bool>; |
There was a problem hiding this comment.
As mentioned in the description of the PR replacing the requires expression using this concept allows GCC 10 to compile the generated C++ code.
Sorry, something went wrong.
There was a problem hiding this comment.
I didn't know that we could write concepts in CPP2 already. Thank you for showing that.
Sorry, something went wrong.
There was a problem hiding this comment.
It was a bit of a stab in the dark, but it worked. In fact this overload is not used at all in this test. One of the first things I tried was simply removing it altogether, which also made GCC 10 happy.
Then I tried to come up with a way to rewrite it to be able to keep it.
Sorry, something went wrong.
| { | ||
| print( "1.1 is int? ", 1.1 is int ); | ||
| print( "1 is int? ", 1 is int ); | ||
| ::print( "1.1 is int? ", 1.1 is int ); |
There was a problem hiding this comment.
Explicit specification of the global namespace fixes an ambiguity issue caused by std::print.
Sorry, something went wrong.
There was a problem hiding this comment.
I was trying to figure out why the cpp1 compiler considers std::print in this call... it looks like that compiler on some platforms makes them globally accessible.
Sorry, something went wrong.
There was a problem hiding this comment.
I also found it strange, esp. that Clang-18 (C++23) was failing only for mixed-type-safety-1.cpp2, while MSVC (latest) was failing only for pure2-type-safety-1.cpp...
Sorry, something went wrong.
There was a problem hiding this comment.
I was trying to figure out why the cpp1 compiler considers std::print in this call... it looks like that compiler on some platforms makes them globally accessible.
cpp2
print( "1 is int? ", 1 is int );
print("\ns* is Shape? ", s* is Shape );
cpp1
print( "1 is int? ", cpp2::impl::is<int>(1));
print("\ns* is Shape? ", cpp2::impl::is<Shape>(*cpp2::impl::assert_not_null(s)));
cpp2::impl::is<...>(...) in these two calls resolves to std::true_type, so std::print is picked up by ADL.
Sorry, something went wrong.
There was a problem hiding this comment.
Ah... right. The argument is from std namespace. I forgot about this rule.
@gregmarr Thank you!
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, I though it was ADL, as I rwrote in the PR description, but I found it strange there was come inconsistency in how differently the recent compiles (MSVC, GCC 14 and Clang-18) behave for mixed-type-safety-1.cpp2 on current main.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, the inconsistency is strange. Do all of those compilers have std::print available with the compiler options that we are using? Otherwise they must just have different disambiguation rules.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for figuring this out! This was on my list to look into and I'm glad to see it's been figured out, much appreciated.
Sorry, something went wrong.
There was a problem hiding this comment.
Should there be a comment there about why the :: is needed, so someone doesn't try to remove it in the future?
Should the function just be renamed?
Can we somehow make the user-facing end result of that is be bool even when it's the compile-time std::true_type or std::false_type so that users don't end up with these same ADL issues? Would that defeat the purpose of using those types in the first place? If so, do the benefits of returning that type outweigh the cost?
Sorry, something went wrong.
There was a problem hiding this comment.
In fact renaming crossed my mind, but I thought full qualification would have extra educational value.
I wile the idea of adding a comment.
Sorry, something went wrong.
There was a problem hiding this comment.
Looks good!
Sorry, something went wrong.
|
Thanks! |
Sorry, something went wrong.
|
What's the best way to resolve the two .output file conflicts? Just delete them and regenerate them post-merge? Normally I'd use the web editor but the button is disabled, saying the conflicts are too complex for the web editor. |
Sorry, something went wrong.
|
Rebased with conflicts resolved. |
Sorry, something went wrong.
|
Thank you! |
Sorry, something went wrong.
|
I have added a comment and I propose to leave the solution with full qualification as it often is helpful when problems with ADL arise (speaking from my own experience).
This is neverending and the devil is in the details... |
Sorry, something went wrong.
|
Urk, it says to resolve conflicts again -- sorry, I may have done that because I just pushed a commit. 😞 Sorry, I didn't think it would interfere with this. I don't know why it disables the "Resolve conflicts" button claiming that the conflicts are too complex to resolve in the web editor, those three files are not that long or complex. Sigh, sorry about that. I tried pulling the branch and rerunning regression on my machine but that didn't hit these files. If you can re-fix these in the next couple of days I'll hold off on other commits. |
Sorry, something went wrong.
|
I will rebase this on #1256 that already makes all tests green. |
Sorry, something went wrong.
It is fixed. In fact this PR is now based on the updates in #1256. You can merge #1256 first. |
Sorry, something went wrong.
|
Thanks! I have merged #1256. For some reason this is still showing conflicts that cannot be resolved in the web editor:
Now that the conflicts are limited to .output files, perhaps the simplest thing is for me to just go delete them from this PR, and re-run regression separately... |
Sorry, something went wrong.
|
This is weird: Only one of those two files exists in the branch. I tried deleting that one and pushed that, but it seems to have had no effect on the merge conflict. Any ideas? |
Sorry, something went wrong.
I will try to fix that soon (as in later today). |
Sorry, something went wrong.
|
Ready to merge. |
Sorry, something went wrong.
|
Thanks! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.