Index: llvm/docs/ProgrammersManual.rst =================================================================== --- llvm/docs/ProgrammersManual.rst +++ llvm/docs/ProgrammersManual.rst @@ -1467,13 +1467,15 @@ .. note:: - Prefer to use ``SmallVectorImpl`` as a parameter type. + Prefer to use ``ArrayRef`` or ``SmallVectorImpl`` as a parameter type. - In APIs that don't care about the "small size" (most?), prefer to use - the ``SmallVectorImpl`` class, which is basically just the "vector - header" (and methods) without the elements allocated after it. Note that - ``SmallVector`` inherits from ``SmallVectorImpl`` so the - conversion is implicit and costs nothing. E.g. + It's rarely appropriate to use ``SmallVector`` as a parameter type. + If an API only reads from the vector, it should use :ref:`ArrayRef + `. Even if an API updates the vector the "small size" is + unlikely to be relevant; such an API should use the ``SmallVectorImpl`` + class, which is basically just the "vector header" (and methods) without the + elements allocated after it. Note that ``SmallVector`` inherits from + ``SmallVectorImpl`` so the conversion is implicit and costs nothing. E.g. .. code-block:: c++ @@ -1488,8 +1490,19 @@ allowsAnySmallSize(Vec); // Works. } - Even though it has "``Impl``" in the name, this is so widely used that - it really isn't "private to the implementation" anymore. A name like + // BAD: Clients cannot pass e.g. raw arrays. + hardcodedContiguousStorage(const SmallVectorImpl &In); + // GOOD: Clients can pass any contiguous storage of Foo. + allowsAnyContiguousStorage(ArrayRef In); + + void someOtherFunc() { + Foo Vec[] = { /* ... */ }; + hardcodedContiguousStorage(Vec); // Error. + allowsAnyContiguousStorage(Vec); // Works. + } + + Even though it has "``Impl``" in the name, SmallVectorImpl is so widely used + that it really isn't "private to the implementation" anymore. A name like ``SmallVectorHeader`` would be more appropriate. .. _dss_vector: