summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2020-09-21 20:48:56 +0200
committerStephan Bergmann <sbergman@redhat.com>2020-09-21 22:15:56 +0200
commite79a6a5270d190d6e89a6acf08e22419386d2117 (patch)
treee5cabdd412d77db160e286fcdf942fce0e68b7d5 /include
parenta2791a8b0de05cec8a94b5bd19a6ff6ee4fd76c5 (diff)
No need to make the OString(std::string_view) ctor explicit
<https://gerrit.libreoffice.org/c/core/+/101829> "Make std::u16string_view -> OUString construction explicit" (which has meanwhile been abandoned) had intended to make the OUString(std::u16string_view) ctor explicit, mostly not for the rationale given in the commit message there (it being "a rather expensive operation"), but rather to avoid anticipated ambiguity issues when introducing e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString"---but which has ultimately been added in a form that did not give rise to such ambiguity issues after all. 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" had added the OString(std::string_view) ctor as explicit to match the corresponding explicit OUString(std::u16string_view) from the above <https://gerrit.libreoffice.org/c/core/+/101829>. But as that has now been abandoned, there is no good reason to keep this ctor explicit, either. Change-Id: I05742de5f3992ad5995149631bf8d55c8d448387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'include')
-rw-r--r--include/rtl/string.hxx2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/rtl/string.hxx b/include/rtl/string.hxx
index e59ffba83a62..7086de15c987 100644
--- a/include/rtl/string.hxx
+++ b/include/rtl/string.hxx
@@ -304,7 +304,7 @@ public:
#endif
#if defined LIBO_INTERNAL_ONLY
- explicit OString(std::string_view sv) {
+ OString(std::string_view sv) {
if (sv.size() > sal_uInt32(std::numeric_limits<sal_Int32>::max())) {
throw std::bad_alloc();
}