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.

Sign up for GitHub

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

Jump to bottom

RFC: Rename BitAnd, BitOr, and BitXor to And, Or, and Xor #12315

Closed
brendanzab opened this issue Feb 16, 2014 · 8 comments
Closed

RFC: Rename BitAnd, BitOr, and BitXor to And, Or, and Xor #12315

brendanzab opened this issue Feb 16, 2014 · 8 comments

Comments

@brendanzab
Copy link
Member

This would make them more consistent with the other operator trait names.
@Thiez
Copy link
Contributor

Thiez commented Feb 16, 2014

How will we refer to && and ||? Logical and and logical or?

@liigo
Copy link
Contributor

liigo commented Feb 16, 2014

I don't like this rename, because of && and ||
2014年2月16日 下午5:50于 "Brendan Zabarauskas" notifications@github.com写道：

This would make them more consistent with the other operator trait names.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12315
.

@huonw
Copy link
Member

huonw commented Feb 16, 2014

In my mind they already are consistent: | does a bitwise-or, & does a bitwise-and, etc. (I guess people colloquially call them 'or' and 'and', but as @liigo says, it causes confusion with logical-or and logical-and.)

@brendanzab
Copy link
Member Author

Short-circuit and/or? or-else/and-also?

@huonw
Copy link
Member

huonw commented Feb 16, 2014

Well... the accepted jargon is bitwise operators vs. logical operations.

@brendanzab
Copy link
Member Author

Hm ok. Should we instead do:

  • Shl -> BitShl
  • Shr -> BitShr
  • Not -> BitNot

Might make things more consistent.

@zkamsler
Copy link
Contributor

Not does not appear to be exclusively bitwise or logical. It depends on what type it is used on.

Adding Bit to Shl and Shr is a bit redundant, in the sense that there is no circumstance in which it could be confused with a logical operation.

@brendanzab brendanzab mentioned this issue Feb 22, 2014
Merged
@rust-highfive rust-highfive mentioned this issue Sep 24, 2014
Closed
@rust-highfive
Copy link
Collaborator

This issue has been moved to the RFCs repo: rust-lang/rfcs#308

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
@bors
Auto merge of rust-lang#12315 - matklad:update, r=Veykril
4bad195 
⬆️ deps
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 26, 2024
@bors
Auto merge of rust-lang#12324 - GuillaumeGomez:useless_allocation2, r…
250fd09 
…=y21

Extend `unnecessary_to_owned` to handle `Borrow` trait in map types

Fixes rust-lang/rust-clippy#8088.

Alternative to rust-lang#12315.

r? `@y21`

changelog: Extend `unnecessary_to_owned` to handle `Borrow` trait in map types
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Thiez @liigo @brendanzab @zkamsler @huonw @rust-highfive