If I were to come across such code I would immediately refactor that to literal bitmasks.
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:
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.
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.)