[libcxx-commits] [PATCH] D116344: [libc++] [ABI BREAK] Conform lognormal_distribution::param_type.

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Jan 10 10:51:50 PST 2022


ldionne added a comment.

In D116344#3232200 <https://reviews.llvm.org/D116344#3232200>, @Quuxplusone wrote:

> @ldionne wrote:
>
>> If it does, we will make this a proper ABI macro and only enable it in the ABI-unstable build.
>
> I agree with everything you said except this sentence. I don't believe we know a realistic path to ever make "ABIv2" the //default//, which means that if we do this patch only in ABIv2, then we're not doing it by default for "new customers" (so to speak). And I think this UB is a big enough deal that it //needs// to be fixed-by-default for new customers. //If// anyone complains about the new `lognormal_distribution` (which I think we both believe is highly unlikely), then I think we would have to investigate some way to keep this patch enabled by default for ABIv1 users, but disabled for those specific vendors who complained — which I think means simply "do exactly this PR, //but// commit to supporting the `_LIBCPP_ABI_OLD_LOGNORMAL_DISTRIBUTION` macro forever."
> (TLDR: I do //not// think it should be acceptable to enable `_LIBCPP_ABI_OLD_LOGNORMAL_DISTRIBUTION` by default in ABIv1, even if we get a few complaints. But again, we'll probably get zero complaints and so it'll be moot, which is great.)

I knew you (or someone else) was going to suggest that, which is why I worded my comment above to unambiguously suggest that the default was going to be "no ABI break". I think there's definitely logic in what you suggest, however the default so far has always be that non-benign [1] ABI breaking changes were opted-into, not opted-out. We could discuss changing that policy, but it's a much much larger discussion. It would indeed make some sense that the library be "unstable" by default, but that we provide mechanisms for vendors to keep their flavour of the library ABI stable. But that's an entirely dynamic for the project and we would need vendors to be organized and to pay attention to what's shipped on their systems a lot more than they need to be today.

[1]: By a non-benign change, I mean a change that affects some people. For example, if we break the ABI in such a tiny way that nobody ever notices cause nobody was ever depending on that ABI, it's a benign change and I'm supportive of not even having a macro for it. That would just make our lives harder without benefit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116344/new/

https://reviews.llvm.org/D116344



More information about the libcxx-commits mailing list