[llvm-dev] RFC: [SmallVector] Adding SVec<T> and Vec<T> convenience wrappers.
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 1 21:07:05 PST 2020
> On 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 <mailto: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 <mailto: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.
>
>> 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)
Totally agree, it isn’t worth fighting this. It is sad that C++ can’t even get std::vector right, but at least it as a language allows us pragmatically make progress here.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/809fddf4/attachment.html>
More information about the llvm-dev
mailing list