use std::string_view.

[gabyx]

Can we usw std::string_view instead of rttr::string_view?

Make an option in the cmake to compile the whole library useing std::string_view or provide a non-explicit constructor which takes a std::string_view?

Can they be interchanged? Does it need major adjustements?

That would be great.

[acki-m]

Whats the motivation for that? The new version 0.9.7 will have minimum requirement C++14. std::string_view is C++17

[gabyx]

The use is C++17. I dont want to interface classes which are 99% the same. :) I can directly use std::string_view :) as I use 17.

Von meinem iPhone gesendet

Am 27.01.2019 um 14:42 schrieb acki-m notifications@github.com:

Whats the motivation for that? The new version 0.9.7 will have minimum requirement C++14. std::string_view is C++17

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[acki-m]

Yeah, but the the new version of RTTR (0.9.7) needs at minimum a c++14 compiler, not C++17. Sorry Gabriel, but I want to keep the interface simple. Having a compile time switch to enable usage of std:.string_view seems to be no benefit for me, instead only a new option which has to be checked and makes it harder to get the right version.

Can we not make some implicit conversion from rttr::string_view to std::string_view, when c++17 compiler is available? I would rather add a new function, instead of adjusting the API.

[gabyx]

Jeah, of course we can also just do that. Adding a non-explicit cast operator. Would that be ok?

[TheAifam5]

Any progress on that?

[Vennor]

Aside from the implicit conversion - which is fine - would it be possible to change the alias rttr::string_view to std::string_view on request through a preprocessor definition?