I don’t mind the “assembler-like” bit operations we already have. There are few places where the everyday programmer needs bit manipulations. One major area this comes to mind is flags. However, I’d rather see a different proposal for how to properly handle flags instead. Another area I see use is for binary file formats. But, that’s usually something for expert programmers. All other areas will be highly specific to a niche and programmers should then learn the appropriate tools (i.e. bit manipulations) specific to that niche. Maybe you are also thinking about embedded systems. But, maybe it is also a good thing that embedded programmers need to get a little closer to the hardware in their programming. Your abstraction will separate them from their hardware instead.

Concerning an optimal solution for some of your proposed function: If performance for these functions is of concern to a programmer he lives in a very specific niche and should know the proper tools for his application. For most programmers it is perfectly fine if the solution is not optimal; it will never be the performance killer inside a loop for them.

To me, it sounds like you want abstractions for those programmers who need to be really close to the hardware (sounds almost like an oxymoron). I personally don’t see a general need for this (see my explanation above). Still, I also wouldn’t oppose it.

> On Jun 26, 2025, at 1:03 PM, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> Hi,
>
> I'm interested in how much appetite there would be for the following set of functions in <bit>:
>
> template<class T>
> T sign_fill(T x) noexcept;
> // Fills the integer with the most significant bit of x.
>
> template<class T>
> T bit_mask(T x) noexcept;
> // Returns (T{1} << x) - T{1};
>
> template<class T>
> bool get_bit(T x, int i);
> // Gets ith bit in x.
>
> template<class T>
> T set_bit(T x, int i);
> template<class T>
> T set_bit(T x, int i, bool b);
> // Sets ith bit in x to 1 and b, respectively.
>
> template<class T>
> T reset_bit(T x, int i);
> // Sets ith bit in x to 0.
>
> template<class T>
> T flip_bit(T x, int i);
> // Sets ith bit in x to its complement.
>
> These kinds of things are building blocks used in bit manipulation all the time.
>
> It's also not trivial to get optimal codegen for all compilers on all architectures. I've actually overhauled the top answer on the StackOverflow post at https://stackoverflow.com/q/47981/5740428, and I can say from experience that not every way to write set_bit(T, int, bool) is equally good.
>
> Sign-filling is a pretty common technique, and writing it out by hand is somewhat tedious because it requires going through std::numeric_limits to do it generically.
>
> Even if we leave these arguments aside, the problem with writing say, (x | (1 << i)) instead of set_bit(x, i) is the lack of expressiveness. It's somewhat like writing inline assembly and then puzzling together that cmp and je collectively perform a jump if two registers are unequal. It's easy if you did it 1000 times before, but not obvious to novice readers at all.
>
> The question is mainly where to draw the line. There are tons of different bit manipulation techniques, like isolating the lowest set bit, etc. However, none of these are anywhere near as common as simple setting/getting specific bits. I cherry-picked creating bit masks and sign-filling because they stand out from the crowd, in my experience. Maybe I could collect some data on this.
>
>
> Jan
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals