Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h | ||
---|---|---|
49 | nit: how about implementing this with std::visit? it's definitely more code, but at least makes sure:
it would look like: Kind kind() const { struct KindTranslator { Kind operator()(Decl *) { return Declaration; } ... }; return std::visit(KindTranslator{}, Storage); } but not feeling so strongly about it, so feel free to keep as is if needed (I don't think we'll add tons of more kinds later on, so the chances of introducing bugs is small. but using new language/library constructs sounds fun). | |
55 | nit: I think it would be better to spell out the types here (and above), rather than rely on what Kind would translate into | |
61 | nit: any particular reason for dropping const here? |
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h | ||
---|---|---|
49 | This is a bunch more code to read, is no longer a trivial accessor when compiled. It does look canonical, but I think this speaks more to std::variant being not great (we don't have a lot of experience with it yet). It's not *that* much more safe, the error enum {A, C, B} can still be expressed as Kind operator()(A*) { return A; } Kind operator()(B*) { return A; /*oops*/ } It's silghtly more locally obvious, but it's buried in a bunch of boilerplate. (It also leans into addressing variants with types, as I mentioned below) | |
55 | This seems backwards to me: the compiler will check that the type is correct, but can't check that the alternative we're fetching matches the accessor we're defining. (As a design question, I think we should to name variants rather than access them with types when this is ergonomic, e.g. it's perfectly reasonable to model header=physical/verbatim/stdlib as variant<FileEntry*, StringRef, StringRef>. Languages that take variants seriously tend to prefer this) | |
61 | Oh, the constructor was nonconst so I assumed const was an oversight. Changed to const everywhere. |
thanks, i agree with your comments around std::variant, let's see what kind of patterns will emerge in the future.
so, still LG, but please address the triple slash issue and const-ness before landing
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h | ||
---|---|---|
40 | triple slashes (here and elsewhere) | |
61 | i guess you forgot to upload the diff? (the constructor was definitely an oversight, thanks for noticing that) |
triple slashes (here and elsewhere)