Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

I don't think it will make sense in general for int. As an arbitrary precision two's complement number, it doesn't have a finite bit representation (negative numbers conceptually have an infinite number of '1' bits, which can be seen in bitwise operations).

If there was a class, say Int32, for some finite representation integers, the bitCount operation would make sense on that. I don't really want to add operations on int that act on a limited number of bits, so int.countBits32() doesn't seem right.

That's just speculations, though. We'll think about it, but no promises.

I think bitCount would be fine if it returned a special value for negative numbers.
I suggest null or -1 so the return type could be int, but double.Infinity would be ok.
Or it could throw an exception, like integer % by zero on the VM.

I don't think we should force people to use some Int32 class when, for some reasonable fraction of programs, in practice all the values are non-negative.

You can write (x & 0xFFFFFFFF).bitCount to always be sure of an int in the range 0..32, and that idiom is easily adapted to bit fields and numbers of bits that are unlikely to have a class, e.g. 17.

Or like logcount in common lisp, count the zeroes in negative numbers.

This comment was originally written by @mdakin

I think expecting programmers to use (x & 0xFFFFFFFF) would be error prone.

How about providing .asUnsigned(n) even maybe .asUnsigned32() and .asUnsigned64() etc. methods? (as mentioned in http://code.google.com/p/dart/issues/detail?id=6486)

Or adding all good variations like bitCount(), bitCount32() and bitCount64() to int?

Another option would be having a class like Bits and move all methods there. But this one is not good.

Issue #10212 has been merged into this issue.

Under consideration, but not in the near future.

Added this to the Later milestone.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

Is this still desirable, after pkg/math was scrapped? Would this go into int still?

I doubt we'll end up moving forward with this given that it's relatively simple to implement for users, so I'm closing this for now.