Skip to content
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

Add lint to replace consts with const fns #2344

Merged
merged 1 commit into from
Jan 12, 2018

Conversation

HMPerson1
Copy link
Contributor

Fixes #2288

I think the "Why is this bad" section in the documentation should have more, but I'm not sure what to put there.

(&["core", "sync", "atomic", "ATOMIC_U32_INIT"], "AtomicU32::new(0)"),
(&["core", "sync", "atomic", "ATOMIC_U64_INIT"], "AtomicU64::new(0)"),
// Min
(&["core", "isize", "MIN"], "isize::min_value()"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MIN/MAX are not bad at all, I'd rather recommend the opposite replacement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add a config option for enabling MIN/MAX on this lint. The opposite replacement might be better suited for a different lint though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petrochenkov why? the MIN is in std::isize::MIN and thus requires the full path or an import. min_value exists on the type

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's actually the main reason I recommend these; fewer paths to import.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sort of assumed that it'd make sense to long-term push people toward the const fn versions over the constants. For the INIT structs, they simply aren't at clear as using new, and for the MIN/MAX structs, the types themselves are already in scope.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the MIN is in std::isize::MIN and thus requires the full path or an import.

Oh. I thought they are associated constants already.
Someone should resurrect that PR.

I sort of assumed that it'd make sense to long-term push people toward the const fn versions over the constants.

Why? Constants exist in the language to represent... constants. MIN/MAX are constants, why would you avoid a feature specifically designed to represent them (except for the full path issue which is a fixable library deficiency). min_value() is longer and has that extraneous call.
(I agree about INIT atomics though.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^ This was a concern about constants and const functions in general.
All the listed constants have specific reasons to avoid them (until rust-lang/rust#28656 is redone), so this PR is okay.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree with you @petrochenkov in terms of making them associated constants. When you do end up redoing that PR, you should include the float constants too, as those don't have associated const fns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, no config option for MIN/MAX then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, leave it out, we'll adjust the lint when it makes sense to behave differently on stable

@oli-obk oli-obk merged commit b863a00 into rust-lang:master Jan 12, 2018
@HMPerson1 HMPerson1 deleted the svar_to_cfn branch January 12, 2018 19:24
@HMPerson1 HMPerson1 restored the svar_to_cfn branch January 25, 2018 20:36
@HMPerson1 HMPerson1 deleted the svar_to_cfn branch January 25, 2018 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants