Address all remaining clang-tidy errors

[vyasr]

Description

With this set of changes I get a clean run of clang-tidy (with one caveat that I'll explain in the follow-up PR to add clang-tidy to pre-commit/CI).

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[ttnghia]

Personally I don't like the idea of removing the name class when constructing an object. Having the name class makes thing looks more obvious and less error prone. In particular, instead of having this:

class_name func() {
  // ... very long code
  return {a, b, c,...};
}

I prefer to have this:

class_name func() {
  // ... very long code
  return class_name{a, b, c,...};
}

[davidwendt]

Personally I don't like the idea of removing the name class when constructing an object. Having the name class makes thing looks more obvious and less error prone. In particular, instead of having this:

class_name func() {
  // ... very long code
  return {a, b, c,...};
}

I prefer to have this:

class_name func() {
  // ... very long code
  return class_name{a, b, c,...};
}

I agree with this as well but will abide by a majority vote.

[mythrocks]

ELI5: Why was this change required? Isn't the old version a valid equivalent?

Is it because of (the equivalent of) the Google Style Guide stating that structs need to be POD/passive objects?

[vyasr]

No, this was necessary because the header file declares this object as a class instead of a struct. We could equivalently have changed the header to use struct instead, but the two should be aligned because under certain compilers (Windows) the results could be ABI-incompatible. See https://clang.llvm.org/docs/DiagnosticsReference.html#wmismatched-tags

[mythrocks]

I'm not sure I've understood the need for this either. Why is repeating the variable name here preferred?

[ttnghia]

Structure binding cannot be captured automatically so we have to use this trick.

[mythrocks]

Structure binding cannot be captured automatically...

In which case then, how was it working before? The definitions of lhs_data etc. haven't changed, right?

[vyasr]

We were getting lucky because gcc implements this as an extension even when only compiling under C++17, but other compilers will not be so friendly: https://godbolt.org/z/9fnq6Ex84.

[mythrocks]

Nit: Why not std::string const& str? It's not like str is being std::move()-ed.

[vyasr]

Good question. I can make this change.

[mythrocks]

A couple of nits and questions. But this LGTM.

[mythrocks]

Personally I don't like the idea of removing the name class when constructing an object.

I agree with this as well.

To me it's a little bit like using auto to define variables for objects returned from a function, whose type isn't immediately evident at the call-site. E.g. std::size_t vs cudf::size_type.

I think I'd prefer the explicit type for clarity, but I'll follow what the team decides.

[vyasr]

Personally I don't like the idea of removing the name class when constructing an object.

I agree with this as well.

To me it's a little bit like using auto to define variables for objects returned from a function, whose type isn't immediately evident at the call-site. E.g. std::size_t vs cudf::size_type.

I think I'd prefer the explicit type for clarity, but I'll follow what the team decides.

I agree with the auto analogy. Even more than Mithun's example, this is the exact mirror of using an auto return type from a function; in that case the signature doesn't have the type because it is inferred from the code, whereas in the case we're discussing here the type is only in the signature and the code grabs it from there. I suspect this preference will also have a lot to do with what other languages a given developer is familiar with.

Personally I like the change, but I don't feel strongly enough to sway the team if other generally prefer the status quo. It seems like the vote is currently 3-1 so I'll go ahead and revert. I'll need to go through and manually revert the changes after removing the rule since these changes are not autofixes, so I'll come back to this tomorrow.

[davidwendt]

Personally I don't like the idea of removing the name class when constructing an object.

I agree with this as well.

To me it's a little bit like using auto to define variables for objects returned from a function, whose type isn't immediately evident at the call-site. E.g. std::size_t vs cudf::size_type.
I think I'd prefer the explicit type for clarity, but I'll follow what the team decides.

I agree with the auto analogy. Even more than Mithun's example, this is the exact mirror of using an auto return type from a function; in that case the signature doesn't have the type because it is inferred from the code, whereas in the case we're discussing here the type is only in the signature and the code grabs it from there. I suspect this preference will also have a lot to do with what other languages a given developer is familiar with.

Personally I like the change, but I don't feel strongly enough to sway the team if other generally prefer the status quo. It seems like the vote is currently 3-1 so I'll go ahead and revert. I'll need to go through and manually revert the changes after removing the rule since these changes are not autofixes, so I'll come back to this tomorrow.

@bdice @shrshi @vuule @PointKernel @karthikeyann @mhaseeb123 @kingcrimsontianyu @lamarr

[vuule]

I like using auto in almost every context. It prevents accidental conversions and my IDE can tell me what type is actually used. I've had to deal with multiple bugs caused by conversions on return, but I don't think I've seen any bugs caused by auto use.

I do understand the annoyance with long functions that return "auto", so I'm not really pushing for such auto use. Fine either way, just wanted to highlight what I see as a benefit.

[PointKernel]

I prefer the explicit return type for better clarity and readability as well.

Also, given that many of our unary constructors are not marked as explicit but should be, using explicit return types is required in such cases.

[bdice]

I prefer return class_name{a, b, c,...}; over return {a, b, c, …};. However, I’ve gotten used to reading this form without the class name and I’m OK either way.

I am fine with using auto in a function’s declared return type like auto function_name(){}, especially when paired with the explicit class name at the return statement which might have some friendly CTAD simplification.

[vyasr]

I think that is enough votes that I will go ahead and revert this change and remove the relevant clang-tidy rule.

[vyasr]

I have reverted the change. @davidwendt could you take another look and see if there's anything else that stands out? This PR has two approvals but given the discussion and subsequent changes I'd like another pair of eyes on it.

[ttnghia]

With the config removed, can we use braces instead of parenthesis in the constructor call? I.e., instead of class_name(...) we use class_name{...}?

[vyasr]

We can, but we have to do it manually. You can't have clang-tidy do that automatically for you. As such, I would prefer not to make such changes in this PR because they're a stylistic improvement that's out of scope of what clang-tidy can do.

[KyleFromNVIDIA]

Approved CMake changes

[vyasr]

/merge