Checking if an Integer is an Exact Binary Power

[Solomon E via Digitalmars-d]

On Monday, 25 April 2016 at 22:15:31 UTC, Solomon E wrote:
> ...
>
> I was hoping to suggest that if isPow2F isn't wrong, it might 
> be used, because it has been proved and checked to be correct 
> in this thread. ...
>

On second thought, no one's going to understand why the code (x & 
-x) > (x >>> 1) parameterized for all integer types is in the 
library, if it ever breaks because of some compiler backend 
problem with the different generated code for the different 
integer types. So I'll take back suggesting that for the library, 
(at least until I or someone else understands why it would never 
break like that.)

The ways to improve D that occur to me based on this are:

(1) It would be better to have a compiler warning on passing 
signed types to unsigned parameter functions. There wasn't with 
popcnt, on GDC 5.2.1. There should be more of other warnings like 
that too.

I like to compile with practically all the warnings & errors on 
when I try writing a little C, such as a chess engine with no 
heap allocation that I wrote in January.

-Wall -Wextra -fno-common -Wcast-align -Wredundant-decls 
-Wbad-function-cast -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wformat=2 
-Wdouble-promotion -Winit-self -Wmissing-include-dirs 
-Wswitch-default -Wswitch-enum -Wfloat-equal -Wconversion 
-Wlogical-op -Wredundant-decls -Wjump-misses-init -Wshadow 
-Wcast-qual -Wvla -Wsuggest-attribute=pure -fipa-pure-const 
-Wsuggest-attribute=const

No segfaults from that program, which was not the case with 
learning to make a thread local class variable in D.

(2) More thorough, precise descriptions in the online library 
documentation. Some things are told in very loose terms, with 
unexpected complexities shown in the examples. See 
std.math.nextPow2 for what I'm talking about. I'd like to rewrite 
the docs, if I could, or maybe an alternate expanded version, but 
it's a lot and it's a moving target.