[llvm-dev] RFC: [SmallVector] Adding SVec<T> and Vec<T> convenience wrappers.
Sean Silva via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 2 16:19:09 PST 2020
On Tue, Dec 1, 2020 at 4:41 PM Duncan P. N. Exon Smith <dexonsmith at apple.com>
wrote:
> On Nov 30, 2020, at 6:04 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> I actually was mildly leaning to the "minimum 0" side, but after writing
> the above I'm now leaning towards "minimum 1".
>
>
> I'm fine with this as well.
>
> On 2020 Dec 1, at 14:33, Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
> Overall, I’d recommend a path like this:
>
>
> This path SGTM.
>
> 1) We decide what to do about the default argument. I agree with Sean
> that SmallVector<T> should default to 1 at the minimum, and produce an
> error or warning of T. This makes sense given the bias towards a name that
> implies inline semantics.
>
>
> As mentioned above, I think minimum 1 makes sense.
>
Thanks Duncan. Looks like we have reached consensus.
I've drafted a patch that adds the default, and added several folks from
this thread as reviewers: https://reviews.llvm.org/D92522
-- Sean Silva
>
> 2) We decide whether we want to ban std::vector in the LLVM code base by
> convention. If so, I think that we should have a *separate* name for the
> out of line case, e.g. llvm::Vector<T>, which would be a good dual to
> llvm::SmallVector<T>. If this is the end point (Duncan seems to think it
> should be) then we should make this part of the coding standard and move
> the code base towards it over time.
>
>
> (Yeah, I don't think we should allow use of std::vector; even though Mehdi
> discovered libc++ was changed, it'll be super frustrating to track down
> compile-time regressions that only occur on the non-libc++ bots or
> something; I don't think the problem goes away until we stop supporting
> being built with standard libraries without this)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/328575aa/attachment.html>
More information about the llvm-dev
mailing list