[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."

[Chandler Carruth via llvm-dev]

On Sat, Jun 8, 2019 at 11:12 AM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, 8 Jun 2019 at 18:18, Mehdi AMINI via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > The LLVM coding style does not specify anything about the use of
> signed/unsigned integer, and the codebase is inconsistent (there is a
> majority of code that is using unsigned index in loops today though).
> >
> > I'd like to suggest that we specify to prefer `int` when possible and
> use `unsigned` only for bitmask and when you intend to rely on wrapping
> behavior, see: https://reviews.llvm.org/D63049
>
> I'd prefer us to have something neater than static_cast<int> for the
> loop problem before we made that change.


Not sure this is much of a problem in LLVM-land... We already encourage a
loop style that avoids the classical problem:

```
for (int Index = 0, Size = MyVector.size(); Index < Size; ++Index) {
  // ...
}
```

Alternatively, LLVM supports a form I like even more:
```
for (int Index : llvm::seq<int>(0, MyVector.size())) {
  // ...
}
```

If passing the explicit type is an issue, we could fix that?

FWIW, I'd also be fine changing the return value ef `size()` for LLVM
containers, and given the variability of standard library container
performance, I'm generally a fan of LLVM code consistently using its own
containers.

-Chnadler


> Perhaps add an ssize (or
> equivalent) method to all of our internal data structures? They're a
> lot more common than std::* containers.
>
> But it's not something that would keep me up at night.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190608/5b56b2b4/attachment.html>