Date: Fri, 18 Sep 2020 11:33:42 +0300
On Fri, 18 Sep 2020 at 09:36, Richard Hodges via Std-Discussion
<std-discussion_at_[hidden]> wrote:
> auto x = tuple [ foo, &bar]; // bar is a tie
> auto x = tuple & [ foo, bar ]; // equivalent to std::tie
>
> In the above trivial example, the presence of the name std::make_tuple adds almost no information. It also creates a type with a long and unwieldy name (that actually causes some compilers to run out of string space!) and an eye-wateringly complex implementation. The presence of std:: adds absolutely none as a tuple is a globally understood concept. The last two examples suggest a similar capture model to that of lambdas, which provides consistency.
Interesting consistency, considering that &bar means address of bar
everywhere else, but reference to bar
in lambda captures.
> Performance:
> Expression through library templates means two levels of translation of intent. One from user intent to expression in terms of existing library code and (sparse) core language features. There is plenty of opportunity for missing concepts in the language to limit the quality of that translation.
> On the other hand, a keyword with code generation behind it means that a users’ specific intent can be translated into optimal code every time. Furthermore, as compiler technology improves, that translation can be improved, improving every program upon recompilation.
> Of course this is partially true of libraries, but the library still suffers from not having access to direct code generation with knowledge of the absolute intent of the programmer.
I don't quite see what the "plenty of opportunity for missing concepts
in the language" might be, and how
make_unique leads into any less-optimized code than writing the same
with operators and sigils does.
> Further:
> Many modern library features rely on compiler intrinsics - from the programmer’s point of view these are required but undocumented language extensions. This is untenable at scale. Better, in my view, to have no intrinsics and simply extend the language to include these obviously essential features. Once that is done, why bother with the complication of a library? Make a tuple a compiler-supported type. Provide class reflection as a language feature. Then it can be easily documented, maintained and shipped with no secret interdependency between compiler and standard library.
Things like tuple and make_unique don't rely on intrinsics. Wrt. "why
bother with the complication of a library?", why bother
with the complication of every compiler?
<std-discussion_at_[hidden]> wrote:
> auto x = tuple [ foo, &bar]; // bar is a tie
> auto x = tuple & [ foo, bar ]; // equivalent to std::tie
>
> In the above trivial example, the presence of the name std::make_tuple adds almost no information. It also creates a type with a long and unwieldy name (that actually causes some compilers to run out of string space!) and an eye-wateringly complex implementation. The presence of std:: adds absolutely none as a tuple is a globally understood concept. The last two examples suggest a similar capture model to that of lambdas, which provides consistency.
Interesting consistency, considering that &bar means address of bar
everywhere else, but reference to bar
in lambda captures.
> Performance:
> Expression through library templates means two levels of translation of intent. One from user intent to expression in terms of existing library code and (sparse) core language features. There is plenty of opportunity for missing concepts in the language to limit the quality of that translation.
> On the other hand, a keyword with code generation behind it means that a users’ specific intent can be translated into optimal code every time. Furthermore, as compiler technology improves, that translation can be improved, improving every program upon recompilation.
> Of course this is partially true of libraries, but the library still suffers from not having access to direct code generation with knowledge of the absolute intent of the programmer.
I don't quite see what the "plenty of opportunity for missing concepts
in the language" might be, and how
make_unique leads into any less-optimized code than writing the same
with operators and sigils does.
> Further:
> Many modern library features rely on compiler intrinsics - from the programmer’s point of view these are required but undocumented language extensions. This is untenable at scale. Better, in my view, to have no intrinsics and simply extend the language to include these obviously essential features. Once that is done, why bother with the complication of a library? Make a tuple a compiler-supported type. Provide class reflection as a language feature. Then it can be easily documented, maintained and shipped with no secret interdependency between compiler and standard library.
Things like tuple and make_unique don't rely on intrinsics. Wrt. "why
bother with the complication of a library?", why bother
with the complication of every compiler?
Received on 2020-09-18 03:33:55