
The C++ Metaclasses Proposal in Less Than 5 Minutes - osopanda
https://www.fluentcpp.com/2018/03/09/c-metaclasses-proposal-less-5-minutes/
======
bla2
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p093...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p0939r0.pdf) says "C++ is complicated,
too complicated, yet we cannot remove significant facilities and changing them
is very hard. Changing parts deemed insignificant can be risky (we need better
analysis tools [Winter,2016]) and the potential gains would be insignificant.
However, we badly need to simplify use of C++" in its long-term goals.
However, almost every short- and medium-term change planned runs counter to
that long-term goal. How are we supposed to reach a long-term goal if every
step taken along the way is in the opposite direction?

~~~
gwbas1c
Maybe a version of C++ that breaks backwards compatibility? The assumption is
that it will only be used for new projects?

~~~
makecheck
That is really the best solution, especially since it’s easier than ever to
partition code bases (e.g. multi-process tools where you’ve only had time to
modernize one of the pieces so far). It’s no longer “new project” so much as
“new piece”.

~~~
johannes1234321
There are such things, for instance D is a "better" C++, but isn't widely
used. By doing a cleanup of a language you throw away libraries, knowledge,
tools, ... See also the missing success of Perl 6.

------
marshray
I just use struct because access defaults to public. Inheritance is almost
always public, and I prefer to declare public members at the top of my class
for readability. I don't see any profound lessons of software engineering
arising from the C++ definitions of class and struct. I don't read class and
struct as having strong semantic conventions communicating intent. I don't see
a significant problem with the way we currently define interfaces using them.

I'm sure I'm just used to things the way they are, but this does not seem to
me like a strongly motivating example for metaclasses.

------
_pmf_
I'm more interested in "C++ Templates in Less Than 3 Years".

~~~
bluGill
Spend two years in haskel, c++ templates will only take you 6 months: net
savings 6 months.

Seriously, once you are good at functional programming (which haskel will give
you) C++ templates are just a syntax problem: you should be able to learn that
awful syntax in 6 months once you don't have the overhead of trying to learn
functional programming at the same time.

------
billsix
If you're interested in learning more about compile time computation, I wrote
a book about it in Lisp.

[http://billsix.github.io/bug.html](http://billsix.github.io/bug.html)

[http://billsix.github.io/cac](http://billsix.github.io/cac)

------
jzwinck
The guidelines say to use class when there is an invariant and struct
otherwise. This is counter productive because if a struct without invariants
suddenly gains an invariant, it should be changed to class. Which doesn't
matter except that all forward declarations now also must change (despite
years of more permissive compilers allowing a forward declaration of a class
later defined as a struct, this is not standard).

Better to always use struct and never class, or the opposite. Always class is
simpler because the first members declared in most classes are public, and
struct saves you typing "public:" at the top of every class. But always class
has the advantage that it is far more popular in C++ library code...including
std::array which has no invariants.

~~~
FungalRaincloud
I can't think of a case where that's not just a quick find/replace to fix. Or,
if you're using a more modern IDE, a refactoring rule.

Do you have something in mind that might be more complicated?

~~~
bluGill
I write a library that is used by many downstream projects. If I make the
struct->class change in my code all my users who have predeclared my class
have to fix their code. They probably won't read release notes, and might be
using a permissive compiler (gcc is, clang is not - at least in my experience)
so it can be a long time before they get weird bugs reports, which take them
time to understand.

------
mcphage
If the best example is interfaces, why not just add interfaces, instead of
having every library contain its own slightly incompatible implementation of
them?

~~~
jcelerier
A much more interesting example is the replacing of Qt or Windows's meta-
object compilers with purely in-language features and without resorting to
macros.

~~~
yoz-y
The ship has probably sailed but had C++ had reflection back when, maybe the
whole Qt paradigm could do without MOCs. I feel that with C++ we have backed
ourselves into a complexity corner and now building more stuff to get out of
it while retaining old habits.

~~~
jcelerier
> The ship has probably sailed but had C++ had reflection back when, maybe the
> whole Qt paradigm could do without MOCs.

well that's exactly a motivating example of the metaclasses paper:
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2017/p070...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r2.pdf)

