Date: Fri, 19 Aug 2022 11:08:18 +0300
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
{ ... }
}
You get the idea, and again, the generic version is optimistic. The point
is, we have to drastically change the programming style in order to "go
generic". This is a fundamental language limitation that should be
addressed, but I am afraid it is not recognized as a problem currently at
all.
Thank You
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
{ ... }
}
You get the idea, and again, the generic version is optimistic. The point
is, we have to drastically change the programming style in order to "go
generic". This is a fundamental language limitation that should be
addressed, but I am afraid it is not recognized as a problem currently at
all.
Thank You
Received on 2022-08-19 08:08:30