Someone noted the other day that both absl and base have WrapUnique, with the former being contained in absl/memory/memory.h. I propose we remove the ambiguity by removing the latter in favor of the former.
Allowing all of memory.h will not have much other effect since most of the rest are backports of various STL things we have, e.g. make_unique, or deal with std::weak_ptr and shared_ptr. Maybe there's something useful in there I missed.
If we allow this, I would make an LSC proposal to bulk-replace one with the other there are currently about 2300 instances of "base::WrapUnique", which seems surprisingly large) and fix the inevitable torrent of ADL and IWYU errors that result.PK
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFDNQPYhstFiDEZS9gcFospnQqskwmNQvf3a6ADiErUx3A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAH%3DT95S1AYfwsRujh2UTSAOG60__3cqXCaWMcSi3ZyvaGc_bzA%40mail.gmail.com.
Hmm. I think it will be a little bit confusing to have two RawPtrs in Chrome. One is the RawPtr template type for MiraclePtr and another will be the RawPtr function from absl.What do we gain from making this migration? I think there was a strong argument for absl::optional due to the unfortunate conversions required. I don't see quite as much benefit from this proposed change though.
On Thu, Aug 26, 2021 at 12:20 PM Daniel Cheng <dch...@chromium.org> wrote:Hmm. I think it will be a little bit confusing to have two RawPtrs in Chrome. One is the RawPtr template type for MiraclePtr and another will be the RawPtr function from absl.What do we gain from making this migration? I think there was a strong argument for absl::optional due to the unfortunate conversions required. I don't see quite as much benefit from this proposed change though.I can't speak to the RawPtr template type for MiraclePtr, as I'm not being kept in the loop on all that :).
The gain here is "not having two valid ways of doing WrapUnique". It's a small gain; I believed the cost was small as well.PK
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFB5Y-o0ed4iYMpA1PtS4cFrfosePzFjG5ob8f9aOevrAA%40mail.gmail.com.
While doing my perf I found this thread, which didn't reach a conclusion. It sounds like Daniel was slightly concerned and there wasn't much other feedback. I still feel like this is a small win. Now that we're further with raw_ptr<>, is the state of the world any clearer? Can people weigh in?
PKOn Thu, Aug 26, 2021 at 11:07 AM Peter Kasting <pkas...@chromium.org> wrote:Someone noted the other day that both absl and base have WrapUnique, with the former being contained in absl/memory/memory.h. I propose we remove the ambiguity by removing the latter in favor of the former.Allowing all of memory.h will not have much other effect since most of the rest are backports of various STL things we have, e.g. make_unique, or deal with std::weak_ptr and shared_ptr. Maybe there's something useful in there I missed.If we allow this, I would make an LSC proposal to bulk-replace one with the other there are currently about 2300 instances of "base::WrapUnique", which seems surprisingly large) and fix the inevitable torrent of ADL and IWYU errors that result.PK
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBPa%3DDJoHtiqfYqaFHqQYR9NjCM0gL0qUEgKiD6JA6sOw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaQuxdZHkfx78wnxufkwEbfUVZH6RXfXWSXE%3DQGtU4-BFg%40mail.gmail.com.