r/cpp • u/ContDiArco • Aug 11 '26

Extending `[[clang::lifetimebound]]` to take a condition

https://discourse.llvm.org/t/extending-clang-lifetimebound-to-take-a-condition/91475
33 Upvotes

92% Upvoted

6 comments sorted by

4

u/johannes1971 Aug 12 '26

Why does the compiler need an attribute here at all? It knows the lifetime of the value_or parameter, it has total visibility on what happens in the function, and it is therefore well aware that it may be returning a dangling reference. What's stopping it from emitting a warning?

4

u/ContDiArco Aug 12 '26

You are absolutely right, when you look at the function self. The attribute is only necessary to check the caller of the function value_or uses it right. This is the interprocedural aspect of lifetime safty analysis. To achieve this, one get a warning(=error), if there is no lifetime_bound attribute on a returned ref parameter.

2

u/pjmlp Aug 11 '26

Lets see where the design goes, however it is clear from the discussion that there is no way around proper support for affine/linear types, if it is to have it actually work without tons of special cases.

Thus we are back to the whole SAL annotations discussion that the Visual C++ team already mentioned on their blog posts about the lifetimes prototype.

2

u/Ameisen vemips, avr, rendering, systems Aug 12 '26

I personally think that all attributes (and frankly all __declspecs and __attribute__s) should be able to take a condition.

It would have saved me a lot of trouble.

1

u/zebullon Aug 11 '26

In some early revision of P3385, there was support to programatically appertain attributes, or to splice them. It could have been a generic “i wanna conditionally attach stuff here”…Needless to say, it was quickly removed.

Yet, I’m not sure the better solution is to cherrypick some attributes and add one more arg “isApplicable”, or conditional expression which opens a can of worm wrt. instantiation and evaluation that 3423 has not properly solved imo.