# A Plea for Bit-Twiddlers! (please keep ! as logical negation, separate from bitwise negation!)
**URL:** https://discourse.julialang.org/t/a-plea-for-bit-twiddlers-please-keep-as-logical-negation-separate-from-bitwise-negation/8297
**Category:** Internals & Design
**Created:** [January 11, 2018, 9:56pm UTC](https://discourse.julialang.org/t/a-plea-for-bit-twiddlers-please-keep-as-logical-negation-separate-from-bitwise-negation/8297 "2018-01-11T21:56:49Z")
**Posts on this page:** 1
**Showing post:** 44
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 13, 2018, 3:57pm UTC](https://discourse.julialang.org/t/a-plea-for-bit-twiddlers-please-keep-as-logical-negation-separate-from-bitwise-negation/8297/44 "2018-01-13T15:57:02Z")
@garrison made this comment on GitHub:
>
>
> \> \`!x\` means \`x != 0\` in C, but in C-like languages you can also use x for \`!isz…ero(x)\` in a Boolean context. \[...\] Since we are strict about the latter, it makes no sense to me to use \`!x\` for \`iszero(x)\`.
>
> I think many people against this change will agree even with this statement. As I understand, the question is whether \`!x\` for non-Boolean \`x\` should be unimplemented and thus error (friendliest to developers coming from other languages; prevents "unexpected" behavior), or instead perform a bitwise not (saves a symbol for use elsewhere; provides "consistency").
>
> \> Another data point: Rust chose \`!\` for bitwise not as well.
>
> This is an important argument in favor of this change. While it seems like it easily could have been controversial, I've yet to find a single blog post deriding the Rust developers for this choice (or even a single complaint, anywhere). Of course, Julia is meant to be more approachable than Rust, but many Rust developers will be coming from C where \`!x\` means \`iszero(x)\`, so if it has not been confusing there, perhaps it will not be here either.
> I think many people against this change will agree even with this statement. As I understand, the question is whether !x for non-Boolean x should be unimplemented and thus error (friendliest to developers coming from other languages; prevents “unexpected” behavior), or instead perform a bitwise not (saves a symbol for use elsewhere; provides “consistency”).
If !x for non-Boolean is left unimplemented in Base, then it can be extended as desired by people like me who want to use it as a generic operator, as Jeff showed, without affecting anybody else’s code.
If it is made to perform a bitwise not, while it saves a symbol, that can be done in other ways (again, see my proposal [A Modest Proposal (for !, &, | and ~)](https://discourse.julialang.org/t/a-modest-proposal-for-and/8330)), also, it is more likely to cause confusion, as it violates the convention in most languages that `!` always returns a boolean value (no matter what it is applied to), and finally, I feel it doesn’t really provide consistency with other boolean operators (such as the relational operators, which also take arbitrary input, and always produce a boolean output).
I think that knowing that `if !a` is always valid is way more consistent than having it work or fail depending on whether `a` is a boolean value or something that can be bitwise complimented.
> I actually consider this to be the strongest argument, in practice, for going through with this change. While it seems like it easily could have been controversial, I’ve yet to find a single blog post deriding the Rust developers for this choice (or even a single complaint, anywhere). Of course, Julia is meant to be more approachable than Rust, but many Rust developers will be coming from C where !x means iszero(x), so if it has not been confusing there, perhaps it will not be here either.
I also googled the issue and asked on some Rust discussion boards, and did find a number of comments wanting to know what the Rust bitwise complement operator is, people seeing that everything else matched C,
they expected `~` to work.
---
_[View the full topic](https://discourse.julialang.org/t/a-plea-for-bit-twiddlers-please-keep-as-logical-negation-separate-from-bitwise-negation/8297)._