erichkeane wrote: > > I would be against said RFC. If you asked me in 1996/whatever, I could be > > talked into it. But we're 30+ years of this behavior. > > Doesn't stop WG21 from changing the behavior 30 years later. ;-) My biggest > concern is actually that C++ is changing exception handling such that we can > no longer hand-wave what this flag means. Does it mean exceptions are enabled > or not? If exceptions are not enabled, why are we requiring their use to be > correct in source? And why do we want this flag to behave differently from > other dialect flags like `-fno-modules` (https://godbolt.org/z/e77sG6Y7d), > `-fno-char8_t` (https://godbolt.org/z/xan9d5M1P), `-fno-wchar` > (https://godbolt.org/z/7nzeeY4Mq), etc. In fact, as best I can tell, this is > the only language dialect mode where we don't act as though we don't know > about the keywords. > > I think the important question is: what breaks if we were to do this? As best > I can tell, nothing. Existing code using the flag continues to behave exactly > as it did before, same with existing code not using the flag. The only issue > boils down to users writing new code and trying to combine it with other TUs > that are not compiled with the flag; but that's invalid anyway for ABI > reasons, so I'm not seeing where the concerns are.
I don't want to change the behavior that drastically. Folks are USED to this, and we should just stick to it. Putting them back into 'this could be an identifier' is a bit of extra FE headache at the cost of being 'different' on this than everyone else. IMO its not worth the effort nor difference. We should just stick to our current behavior, except allow discarded/uninstantiated statements. https://github.com/llvm/llvm-project/pull/139859 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
