[PATCH] D130055: Clang extensions yolo, woot & kaboom

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 27 12:30:42 PDT 2022


aaron.ballman added a comment.

Thank you for this! I'm starting to get dug out from standards meetings and able to think about this a bit more, and I had some questions.

> The yolo attribute denotes a constructor as creating an "uninitialized" variable.

Are there circumstances where we cannot "simply" infer this from the constructor itself? (After instantiation) we know the class hierarchy, we know the data members, and we know the ctor init list/in-class initializers, so it seems like we should be able to recursively mark a constructor as yolo for the user rather than making them write it themselves. It seems like inferring this would reduce false positives and false negatives (in the case the user marks the constructor incorrectly or the code gets out of sync with the marking), and we might only need this attribute in very rare circumstances (or not at all, as a user-facing attribute). Is that an approach you're considering?

> The woot attribute appliest to member functions noting that they initialize the base object.

Fully? Partially? I'm trying to decide whether this is only useful for functions named `init()` and `clear()` and the like, or whether this is useful for functions like `setWhatever()` where you can have a partially constructed object that is not fully initialized by any one member function.

> The kaboom attribute applies to member functions noting that they must have an initialized base object.

Same question here about fully vs partially initialized. e.g., where you have a partially constructed object and you can only call `getWhatever()` after `setWhatever()` has been called.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130055/new/

https://reviews.llvm.org/D130055



More information about the cfe-commits mailing list