It was fixed by making the category source a constexpr variable, and each is given a 64 bit random unique id by its author from random.org. If the ids match, the domains are considered equal.
That's something I was considering for Boost.System (literally the same thing, a random 64 bit ID). Unfortunately, the virtual destructor makes error_category a non-literal type, so categories can't be constexpr variables. Hence, my earlier inquiry about the switch to a protected nonvirtual ~error_category.
status code domain has a trivial destructor, and thus is 100% constexpr end to end of its lifetime. You should be aware Peter that your input during the previous discussions was unusually valuable in deciding the design of <system_error2>. Sufficiently so that I previously have mentioned you by name in the private discussions as having given particularly valuable feedback. Thank you. Something I've probably not mentioned to you before is that you called the `filesystem::path` design right during its peer review. Your proposed design was the correct one. The one which ended up being chosen and is now to be standardised is inferior to your design. AFIO chose your design for its path_view. It's considerably the better for it. BTW, I'm not sure if you or Boost is aware, but WG21 is busy making all of the std::filesystem error_code APIs throwing as well as error code returning i.e. they might fail either by error code, or also by throwing an exception, and to date I have not seen a clear articulation of when which will happen other than error_code being used for "file errors" and exception throws for "non-file errors", whatever that means. They expect to complete this "improvement" at Jacksonville by retroactively modifying the C++ 17 standard via the defect process, as apparently the original noexcept semantics is a defect. You can see more at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#3013, keep reading down to see more madness. I'll state now on the record that some parts of WG21 clearly most be smoking something real good for such an action to make any sense. I know that it was originally intended that Filesystem ought to throw in its error code overloads around a decade ago, but ASIO's supremacy has changed what the C++ user base expect when they see an error_code& API. They expect that all failures will be indicated by said error_code&. So should Filesystem, as indeed the C++ 17 standard said it would. Because that's the widely understood convention now. Undoing that now, when you could just set ec to std::make_error_code(std::errc::not_enough_memory) or whatever is backwards and retrograde in my opinion. And besides: some stats from AFIO for ext4 on Linux on a 3.4Ghz Ivy Bridge machine with a budget Crucial MX100 SSD: create file: 6453 ns enumerate file: 192 ns open file read: 1133 ns open file write: 1195 ns delete file: 12338 ns Those are *nano*seconds. A throw-catch cycle is at least 1000 ns. What the f*ck are WG21 smoking on intentionally adding more exception throws in here on Filesystem? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/