[PATCH] D55517: Remove `_VSTD`

Eric Fiselier via Phabricator reviews at reviews.llvm.org
Mon Dec 10 19:14:37 PST 2018

EricWF added a comment.

In D55517#1326178 <https://reviews.llvm.org/D55517#1326178>, @__simt__ wrote:

> Hello Eric, everyone else,
> We have projects that are getting great mileage from this macro right now, we'd be sad to see it go. 😰
> If you look at https://github.com/ogiroux/freestanding you'll get the gist of what we're doing with it: //we don't just change the inline namespace name, we also change the// `std::` //namespace name using the macro//. This was never the intended use, I realize, but it allows us to make progress with e.g. side-by-side co-existence for a large & important subset. In other words, the presence of this macro helped make libc++ adaptable the way needed it to be, and may slowly transform us into contributors even (hence netting you great mileage too).

Thanks for the input. Indeed this was never a supported or intended use case.

I don't fully grok exactly what your need and how you're hacking up libc++ to meet it
(And I'm surprised it has managed to get you this far).

libc++ internals are just that: internal. Any external usage of the is unsupported,
and libc++ should make no attempt to support people who use and abuse them. The design
and maintenance of libc++ cannot be held at the behest of such users.

However, libc++ is receptive to the needs of vendors and your case shouldn't be any different.

First we need to know why use case exists, the details of it, and the rational behind it.
Then we can //design// and //document// a solution that works for both libc++ and the
vendor; one that is maintainable and testable.

I understand you're usage of libc++ is in it's infancy, and I would like to help you grow into
full fledged contributors. I suggest mailing a design document to the libc++-dev mailing lists
which explains your use case in detail. Only then can we start work on a solution.



More information about the libcxx-commits mailing list