# Forbid -(unsigned integer)

**URL:** <https://internals.rust-lang.org/t/forbid-unsigned-integer/752>\
**Category:** ideas (deprecated)\
**Created:** [November 5, 2014, 5:10pm UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752 "2014-11-05T17:10:38Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![nagisa](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nagisa/32/2210_2.png) [@nagisa](https://internals.rust-lang.org/u/nagisa)\
**Post date:** [January 18, 2015, 12:11pm UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752/21 "2015-01-18T12:11:47Z")

</div>

If I were to come across such code I would immediately refactor that to [literal bitmasks](http://is.gd/QaSnPo).

When one encounters something similar, and that is not `-1u` or `!0u` (the obvious cases), the programmer reading the code has to spend some time at each bitmask to figure out what it is supposed to look like. Were such mask be used often across the codebase, some `consts.rs` should then contain:

```rust
pub const DESCRIPTIVE_NAME: u32 = 0xFFFF_FFF6;

```

saving anybody from having to write whatever long incantation every time (s)he wants such a mask.

To me, it sounds like the removal of `-unsigned_int` would overall benefit the bit-fiddling use case.

---

<div class="post-metadata">

**Author:** ![pnkfelix](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pnkfelix/32/110_2.png) [@pnkfelix](https://internals.rust-lang.org/u/pnkfelix)\
**Post date:** [April 1, 2015, 7:49am UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752/22 "2015-04-01T07:49:13Z")

</div>

So we discussed this at the weekly meeting today:

[https://github.com/rust-lang/meeting-minutes/blob/7bb395946c0ded0068b1e61338e135a9dc9a8ff3/weekly-meetings/2015-03-31.md#feature-gate--expr](https://github.com/rust-lang/meeting-minutes/blob/7bb395946c0ded0068b1e61338e135a9dc9a8ff3/weekly-meetings/2015-03-31.md#feature-gate--expr)

The general consensus was to feature-gate unary-negate on unsigned integers.

I am in the process of implementing that now.

However, one gotcha I did not anticipate: its easy to catch applications of the negate operator to expressions of unsigned int type. What may be harder to disallow via a feature gate is passing an unsigned int to generic code that parameterizes over the `std::ops::Neg` trait. We will see.

cc @nikomatsakis : (If you have any bright ideas on catching the latter, let me know. I’ll try to figure something out on my own in the meantime.)

---

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [April 1, 2015, 9:26am UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752/23 "2015-04-01T09:26:57Z")

</div>

I’d just remove the impl of `Neg` for unsigned types.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [March 25, 2019, 8:23am UTC](https://internals.rust-lang.org/t/forbid-unsigned-integer/752/24 "2019-03-25T08:23:05Z")

</div>

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

[Previous page](https://internals.rust-lang.org/t/forbid-unsigned-integer/752.md?page=1)