AaronBallman wrote: > > 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. > > If we push for a deprecation and make projects migrate, propose something for > standardization and the spelling or some other aspects change in the process, > we would force two migrations on our users. I think the right course of > action here might be to not deprecate the current behavior but propose the > new spelling for standardization and only have one wave of deprecation when > the new spelling is approved. What do you think?
That's along the same lines of what I was thinking, yeah -- basically, let's try to learn what we can about how our offerings are working in practice, what deficiencies we may have, and see if there's a sufficiently different approach to be worth considering. If there is, then we could iterate on that design until we're happy enough with it, and deprecate at that point. I suppose one up-front question is: do we think we've had enough time to learn about what's working well and what's deficient or is it premature to think about this now? > > For example, with virtual inheritance, overriders cannot generally have a > > more lax specification than the base function, but you can with > > lifetimebound > > I would argue that this is something that we want to diagnose (as a warning). > That being said, we could do the same with declaration attributes. If we wanted a warning only, I think a declaration attribute makes more sense because it's common to add extra information to derived functions like that: https://godbolt.org/z/vvY1s7b6M If it's part of the type, then it should be an error because the two functions do not correspond due to having different types. > > It's not an implication, it's the behavior specified by the standard. > > I understand that part but I would argue that the standard is quite > inconsistent. E.g., contracts have the position behind the parameter list, > yet they apply to the declaration and not to the type. Yup, you also have things like `= default;` and `= 0;` which trail but don't impact the function's type and things like `noexcept` which used to not impact the type but now do. Then there's bit-fields which somehow both impact the type and don't impact the type at the same time. Declarators are complicated. :-D https://github.com/llvm/llvm-project/pull/196549 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
