AaronBallman wrote: > We added `lifetimebound` about 8 years ago and it got adopted in various > codebases including abseil, chromium, webkit, unreal engine, and more. I > think we need a very strong reason to break the backward compatibility at > this point.
That's unfortunate; a few of us were operating under the hope that this design was not calcified. For background, this was found when we discovered `lifetime_capture_by` having the wrong design for its arguments (https://github.com/llvm/llvm-project/issues/192102) and then started looking deeper into the feature space and found this issue. I don't think this is broken enough to break significant projects by landing this PR, but it is sufficiently problematic that I think it's worth considering deprecating it and replacing it with an improved design (given the issues, I suspect there are other design changes the community may want to consider based on what we've learned from the current approach). I know that's a fair amount of effort though and we could maybe just live with these being kind of broken... but at the same time, I couldn't support standardization for these (as-is) either and that's unfortunate given the interest both C and C++ have in improving safety around lifetime. > I believe the original motivation for the spelling was to match the regular > method declaration syntax: > > ``` > struct S { > void m() const & { ... } > }; > ``` > > Note that the cv and ref qualifiers that appertain to the implicit this > object are at the position after the parameter list. Yes and both impact the type of the function, which is the expectation that lifetimebound fails to meet: https://godbolt.org/z/oTbex5191 and that results in accepts-invalid code like: https://godbolt.org/z/4KrExPzj7 > This makes it natural for developers to put annotations that appertain to the > implicit this object at the same position. I disagree that this is natural but I'm also coming at it from a language lawyer perspective; this feels like "it's natural because we can slide it around to what actually makes sense and so the user doesn't have to worry about it" and not "it's natural because it fits with the design of the language." For example, with virtual inheritance, overriders cannot generally have a more lax specification than the base function, but you can with `lifetimebound`: https://godbolt.org/z/q1e1vG9Mc > It is unfortunate that this also implies that the annotation belongs to the > type and not to the declaration. It's not an implication, it's the behavior specified by the standard. W https://github.com/llvm/llvm-project/pull/196549 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
