[PATCH] D117114: [llvm][ADT] Implement `BitVector(std::initializer_list)`
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 12 19:33:34 PST 2022
dblaikie added a comment.
In D117114#3238494 <https://reviews.llvm.org/D117114#3238494>, @dexonsmith wrote:
> It might be awkward to add this new ambiguity. I wonder if we really want to copy that from `std::vector<bool>`, which doesn't have a great API for bitsets anyway. @dblaikie, any thoughts?
Re: the ambiguity: We could pre-empt that in a separate commit by making the ctor "explicit" - honestly I think we shouldn't be using {} to call user-defined ctors that aren't representative of/"Feel like" conversions. (wouldn't mind that as a broad style statement for LLVM and/or in the form of "mark multi-arg ctors explicit unless they're intentionally converting/structural constructors".
What aspect of "not greatness" API design do you mean - having both the `(unsigned bool)` and init list ctors at the same time? I think with the former being marked as explicit it's /probably/ OK to me? () does "interesting" things, {} represents the value in some sense.
I wouldn't object to a named ctor either, though. (for either case - though I sort of feel like the existing `(unsigned, bool)` is the one that could use a name moreso than the new one (if the new one is only via init list, at least - if you could spell the new one as "SV(true, false, true, true, ...)" yeah, maybe having a name would be good))
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D117114/new/
https://reviews.llvm.org/D117114
More information about the llvm-commits
mailing list