AaronBallman wrote: I think I've got a good handle on the benefits of using a flag and agree with many of them, but the points @MaskRay bring up are still unaddressed regarding the complexity of supporting that flag and whether it's worth that complexity right now. Specifically:
> The current patch emits an error for C input and a warning for assembly > input. There may be other interaction that is worth considering. The > complexity all arises from we introducing a driver option. We have to consider how this impacts more than just C and assembly, but also offloading targets (which may have ABI implications if the offload target supports using the STL), interactions with other command line flags (what happens when the user does `-fhardened -U_LIBCPP_HARDENING_MODE`), etc. So if the libc++ maintainers have a strong opinion about the flag, I think more work needs to be done to ensure a good user experience. IMO, going with the macro for now sidesteps that and still provides a reasonable user experience, even in C++. For example, Microsoft's STL has users define `_ITERATOR_DEBUG_LEVEL` or `_SCL_SECURE_NO_WARNINGS` to control similar behavior in the STL, so it's not just a C standard library thing. That said, I'd be curious to hear if any of the MS STL maintainers have found the macro approach to be a significant problem or burden for them; that would be really interesting information (CC @StephanTLavavej @CaseyCarter). Personally, I think going with the macro until the flag has more functionality it controls makes sense. However, I'm also not opposed to a command line option so long as we're mindful of the user experience around it. I do want to push back on something specifically, though: > IMO, shipping a new feature where macros are the canonical way of controlling > that feature is backwards. It provides a poor user experience and it is > modules-hostile. Macros are used heavily in the industry both in C and in C++. "Modules don't play well with macros" is not a compelling reason to avoid macros, it's a compelling reason to go back to WG21 with feedback that modules have a problem that needs to be solved. https://github.com/llvm/llvm-project/pull/78763 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
