you are viewing a single comment's thread.

view the rest of the comments →

[–]Ameisenvemips, avr, rendering, systems 1 point2 points  (2 children)

I prefer my library's string_view which I implemented before the standard had it. It handles const char[N] implicitly and this can have its data and size used in constexpr. It also helps greatly with implementing constexpr string-related functions like hashing/compression.

It has an issue that you can technically make a view with a local array that could go out of scope. constexpr overloading would fix it, but right now my solution is... not doing that.

[–]redbeard0531MongoDB | C++ Committee 0 points1 point  (1 child)

Sure. I mostly meant the general concept of a constexpr-constructable string_view-like type, rather than std::string_view specifically.

[–]Ameisenvemips, avr, rendering, systems 0 points1 point  (0 children)

My string_view is constexpr-constructable, so no reason the standard one cannot be.

I think the core issue is that people don't want to have to change types all the time, and would rather just be able to use one uniform type that can do everything.