31–40 of 83 posts
Earlier quoted context omitted.
That sounds like concepts, as used extensively in the OP.
One significant difference with concepts is that they are optional.
Earlier quoted context omitted.
Probably because you are used to the paralysed C++ pre C++11. Nothing happens for years and now we have new functionalities every three years supported by all major compilers. But, also, many new functionalities are not for global consumption. The audience of many meta programming functionalities are library developers for example.
Isn't every developer in a non-trivial software project a library developer? As soon as you have a common piece of functionality you want to reuse - that's a library.
A library, specially a C++ library, is way more than reusable code. Developing a library requires the developer to spend time making fundamental design decisions that he doesn't have to make when developing a module lost somewhere within a project tree, such as how to organize the project into interface and private source files, how the lib should be deployed, how to meet upstream dependencies, how to not break compatibility with previous releases while making your code resilient to subsequent changes, how to add metadata to your project, how to handle optional features, etc etc etc.
Earlier quoted context omitted.
And that's exactly what's different in D, where the audience for meta-programming is "everyone". It's not just about more power, but how accessible this power is. To think you need to suffer to have this power is not true.
Nothing stops "everyone" from using the features which suit library developers.
Earlier quoted context omitted.
Isn't every developer in a non-trivial software project a library developer? As soon as you have a common piece of functionality you want to reuse - that's a library.
I think that's dependent on language culture. Because the C++ community doesn't take language simplicity or comprehensibility seriously, there are lots of C++ developers who can't use or reason about surprisingly large parts of the language. So the community has rallied around the notion that "library" developers need to understand everything and that most developers will just glue together bits that the library devs…
Earlier quoted context omitted.
Probably because you are used to the paralysed C++ pre C++11. Nothing happens for years and now we have new functionalities every three years supported by all major compilers. But, also, many new functionalities are not for global consumption. The audience of many meta programming functionalities are library developers for example.
And that's exactly what's different in D, where the audience for meta-programming is "everyone". It's not just about more power, but how accessible this power is. To think you need to suffer to have this power is not true.
Similarly operator overloading via a string that tells you what you are overloading seems... insane? Very error-prone & complex?
Not that C++ is great here or anything, but it seems disingenuous to claim D's complex thing is for everyone while C++'s nearly equally complex thing is too complex for everyone.
Earlier quoted context omitted.
One significant difference with concepts is that they are optional.
Gradual typing is mostly a good thing for metaprogramming I think. Even if it was just a compromise for backwards compatibility I'd still take it over C#'s rather limited generics.
Why is it every time I see a new article about C++ features my eyes glaze over? Am I just getting old, or has C++ jumped the shark?
"a somewhat more awkward and uglier, yet slightly more correct way... all the functionality is right there. We’re not missing anything" might as well be C++'s motto :)
Oh my. If only C++ would have used proper macros from the start...
Earlier quoted context omitted.
And that's exactly what's different in D, where the audience for meta-programming is "everyone". It's not just about more power, but how accessible this power is. To think you need to suffer to have this power is not true.
Nothing stops "everyone" from using the features which suit library developers.
As an example, we needed locked containers, so wrote a little template and specialized it over the couple of containers we needed. It supported just what we needed. If this same functionality were extended to the standard container library it would not only have need to be thought out to handle every non-locking case, but would have either needed a lot of repetitive boilerplate (and repetitive specializations) or else additional hair that was not worth our while to learn/use. We were able to avoid the problem by adding some documentation in the local style guide.