ldionne requested changes to this revision. ldionne added a comment. This revision now requires changes to proceed.
After thinking about this for some more, I'm not sure this patch is worth doing in its current form. The minimal patch for allowing specializations of `allocator_traits` would be: 1. move the `__move_construct_forward` & friends functions from `allocator_traits` to private static member functions of `std::vector` (because they're only used in `std::vector` right now). 2. keep the SFINAE on the allocator and avoid encoding any `memcpy` decision at the call site. However, an even better alternative would be to look into adding an overload to `uninitialized_move` & friends that takes an allocator. We could then be clever in how this is implemented. The major benefit I see here is that there would be one common code path to optimize, as opposed to a `std::vector`-specific code path. Given the small benefit provided by this patch, my opinion is that it's not worth moving forward with it as-is. However, I believe either of the two alternatives suggested above would be welcome, with a preference for the more comprehensive second approach, which requires a paper. Arthur, what do you think? Do you think the second approach can work? Repository: rCXX libc++ https://reviews.llvm.org/D49317 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
