ilya-biryukov wrote: > One question is whether the reflection proposal would address something like > this. If it does, it might make more sense to invest in that than a custom > solution.
That seems like a great long-term direction, but the amount of investment between the two is also vastly different. I think we can either have something like an attribute now, or wait quite a long time for the reflection proposal to flesh out and be implemented. I think the reality is that this particular PR is **only** exploring a solution we can get relatively quickly and with relatively little effort. (Which also puts a burden on it to not cause too much maintenance cost in the long term, obviously, we don't want a quick hack that doesn't really scale or is too expensive in the long run). > ...cat is already out of the bag... Definitely agree, it's quite a nuanced topic. > I think even [[clang::diagnose_if(...)]] can cause template instantiations > that change program behavior. Unrelated, but I'd be curious to see those if you have any examples. I thought that maybe SFINAE could cause this, but at least [in simple examples](https://gcc.godbolt.org/z/5EeMhr4nW) `diagnose_if` does not affect overloading. > My reason is slightly different though: the moment we have another analysis > to add to the picture (something other than lifetimebound), we might run into > a case where we want one part of the spec for one analysis, and another for > the other... and I can't think of a decent way to do that. At the same time, > I'm not sure how likely that scenario is? I definitely have the same concerns, every single analysis makes things more and more chatty and I already feel we're close to a tipping point where annotating things becomes too hard. FWIW, it would be great to get something that "magically" works with a single attribute and does not need complicated compile-time computations. If we cannot get that, the approach with `clang::lifetimebound_like` seems like the second-best alternative. It's simple and show allow modelling functions forwarding to constructors in STL: `make_unique`, `emplace_back`, etc. Seems like a huge win, even if it's not modelling all the nuances that more sophisticated lifetime annotations could achieve. I believe @hokein was about to prepare a list of interesting code examples that we want to support. It would probably be great to that and see how many we can cover with various options, it should help us make a more informed decision. https://github.com/llvm/llvm-project/pull/125520 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
