New range based set methods have caused ambiguity about dynamic_bitset

[Izaron]

Yes, I was thinking about this issue and wrote this in the closed PR:

But I have a serious doubt connected with implicit conversions from int to bool.
If a programmer paid no attention to warnings and/or had to code really fast, he could write this:

int okay = 42;
/* Transforming 'okay' */
db.set(pos, okay);

The last line was supposed to be db.set(pos, okay != 0) according to the current state, but having a new function dynamic_bitset& set(size_t n, size_t len, bool value = true) makes it into db.set(pos, okay, true) implicitly, which seems to me a serious thing...

And well, it already caused some problems. I consider a possibility to rename this function to smth else. We may have the only function set but multiple versions of function, let's say, change, that do range operations.

[jeking3]

Sounds good to me. Are you going to issue a PR for that?

[mclow]

Please resolve this (or revert this) before the freeze beta (7-Nov on the development calendar)

[jeking3]

@mclow got it.

[jeking3]

A simpler resolution is to require the "val" to be specified. It allows us to keep the set() name but for range based set you have to indicate what you are setting it to. Seems better than having a differently named change() just for range, or set_range(). If we did set_range, we would need reset_range and flip_range, which really isn't necessary.