New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not recommend un-approved preview switches #12425
Do not recommend un-approved preview switches #12425
Conversation
Thanks for your pull request, @Geod24! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#12425" |
See conversation here: #12413 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All tests need to be changed back though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the contrary, if people are looking for this behaviour and expect it to work (e.g. because they are coming from C++) telling them what switch they should activate to enable it is the most useful information the compiler can provide.
The exact message can be reworded to be more neutral about it but the information should still be provided.
Also preview=rvaluerefparam
is not exactly unapproved
See my comment, this only triggers in a very narrow case which isn't very helpful to the user, not consistent.
I disagree.
See discussion here: #12064 (comment) |
How so? this is much better than nothing.
That is a different problem, one that is fixed by adding more messages like this, not less.
We shall have to agree to disagree, then.
#12064 (comment) , #12064 (comment) , #12064 (comment) (? maybe I'm too tired atm) I'm not sure what point you're making here.
of #12413 ? Not unless |
It only triggers for default arguments, while in the majority of cases the users would find it more informative to see this error message on
Exactly, fixing the bug is a different problem from informing the user about
Yeah, nothing about this is official. I would have no problem recommending it if there was a plan to make it the default. As it stands, the switch will be usable from this release. It obviously needs more discussion and testing before being recommended to unsuspecting user.
Yes, that's what I meant. And the reason I mention this revert is, when in disagreement, we tend to revert. The original PR was merged while there was a disagreement on how to proceed with it. II submitted the current PR to fix this. If you don't agree with this (12425) PR, I'll just revert the original PR, because I really don't think we should be recommending those switches. But I hope that's not the route we're going. |
Neither '-preview=in' nor '-previiew=revaluerefparam' has been approved by the BDFL. '-preview=in' will require a proper DIP process before being made the default, and DIP1016 which '-preview=revaluerefparam' implements has been rejected. Moreover, such a message would only show up in a very narrow corner case: in the semantic of a default argument which is 'ref' but has a rvalue.
63663cc
to
69a1639
Compare
Yes but this is
OK, ...
... (I disagree entirely with this, diagnostics should go with their fixes) ...
|
@Geod24 @thewilsonator how should we proceed here, given #12428 ? Maybe we should continue suggesting |
ping @Geod24 @thewilsonator |
@RazvanN7 I think ultimately @WalterBright and @atilaneves should decide on the policy that we should follow. |
Although that was the point of "un-approved". Neither of those switches have seen approval from the BDFL. If it was |
@razvan I have email Andrei regarding the dip, we are still waiting for an answer from walter for the question that asked by Andrei, regarding the rvalue dip. |
I understand I wrote the implementation, but that was to try it out. @Geod24 is correct that we shouldn't be recommending it if it is unapproved.
Merging as per above decision and rationale. |
Neither '-preview=in' nor '-previiew=revaluerefparam' has been approved by the BDFL.
'-preview=in' will require a proper DIP process before being made the default,
and DIP1016 which '-preview=revaluerefparam' implements has been rejected.
Moreover, such a message would only show up in a very narrow corner case:
in the semantic of a default argument which is 'ref' but has a rvalue.