Date: Fri, 19 Aug 2022 18:07:35 +0000
On Friday, August 19th, 2022 at 1:08 AM, Михаил Найденов via Std-Proposals <std-proposals_at_[hidden]> wrote:
> Hello,I am reading about efforts to improve generic code development, in particular introducing the so-called Customization Points/Functions. What is a bit odd to me is, the issue of the usage, of how the code looks, is not questioned. The fact something that should be a member function is now a free function, behind a specific namespace is not addressed. I am well aware of the reasons why (I think I read all the papers), but this does not change the fact, we stray more and more away from "Generic code is just normal code". Mind you, we did it already with type_traits - instead of querying the template type for an associated type, we need a "free function", in the form of type trait, to get that type. Once we go the same route with function calls, we basically given up on generic code being normal code:
>
> Normal code:
>
> void function(string s) {
> using char_t = string::char_type;
> // ...
> if(s.begins_with(something))
> { ... }
> }
>
> Generic form (optimistic in terms of syntax...)
>
> template<String S>
> void function(S s) {
> using char_t = stings::traits<S>::char_type; //< we need hoops
> // ...
> if(strings::begins_with(s, something)) //< we need hoops
> { ... }
> }
It's a valid observation. The generic form could be
as simple as
generic<String S>
void function(String s) {
using char_t = String::char_type;
// ...
if(s.starts_with(something))
{ ... }
}
where even std::vector<char> can
adapts to String protocol locally:
override String for std::vector<char> {
using char_type = char;
bool starts_with(this auto const &v, std::string_view s) {
return rg::starts_with(v, s);
}
}
> Hello,I am reading about efforts to improve generic code development, in particular introducing the so-called Customization Points/Functions. What is a bit odd to me is, the issue of the usage, of how the code looks, is not questioned. The fact something that should be a member function is now a free function, behind a specific namespace is not addressed. I am well aware of the reasons why (I think I read all the papers), but this does not change the fact, we stray more and more away from "Generic code is just normal code". Mind you, we did it already with type_traits - instead of querying the template type for an associated type, we need a "free function", in the form of type trait, to get that type. Once we go the same route with function calls, we basically given up on generic code being normal code:
>
> Normal code:
>
> void function(string s) {
> using char_t = string::char_type;
> // ...
> if(s.begins_with(something))
> { ... }
> }
>
> Generic form (optimistic in terms of syntax...)
>
> template<String S>
> void function(S s) {
> using char_t = stings::traits<S>::char_type; //< we need hoops
> // ...
> if(strings::begins_with(s, something)) //< we need hoops
> { ... }
> }
It's a valid observation. The generic form could be
as simple as
generic<String S>
void function(String s) {
using char_t = String::char_type;
// ...
if(s.starts_with(something))
{ ... }
}
where even std::vector<char> can
adapts to String protocol locally:
override String for std::vector<char> {
using char_type = char;
bool starts_with(this auto const &v, std::string_view s) {
return rg::starts_with(v, s);
}
}
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2022-08-19 18:07:45