Followup, having read the new paper, all good, a few notes:
* I think 'making C++ more teachable' could also be summarised as KISS
principle - which C++ as a whole is sorely lacking. 'Gotchas' and
pitfalls fit into a slightly different category, but are not the main
problem. The problem is the overcomplication and seemingly endless
screeds of nuance you have to acknowledge in order to become an
'advanced' C++ dev. Simplification is however often, but not always, at
loggerheads with the ability and desire to create shared forms across
domains. Game dev is one of the most complicated domains, anything that
simplifies is welcome.
* Avoid negative performance impacts - I would add 'and variable latency
in most cases' to that.
* "We've have seen in the past some C++11 date-time utilities using heap
to our surprise." - this feels like an implementation problem, I don't
know if specifying non-heap use only is generally-frowned upon by lewg
as an overreach of specifity, but it could be.
* [[side_effect_free]] - [[pure]] is better. D language already has
pure, which means the same thing, and 'pure' has more historical
relevance due to functional programming etc. This would imply no
non-const reference/pointer parameters, and no changes to global state.
Might be difficult to enforce when passing complex objects which have
interactions within the system, so might also imply no non-trivial
parameters or initialisation of non-trivial types. Otherwise how do you
easily detect that the initialisation of a global non-trivial type isn't
altering global state?
* "A common mistake we noticed with std::move, is the following:" -
this, along with missing semi-colons and a great many things, is a
compiler issue. Should be easy enough for GCC et al to put a warning in
there when detected. They should raise it with compiler devs.
* "An opt-in exception model would solve this problem." - unsure how the
ability to disable exceptions at the compiler end doesn't solve this
problem. Maybe something to do with third party libraries/DLL's? Would
be useful to specify.
* "The fact that code in the not-taken branch of an if constexpr
construct has to be valid is sometimes annoying." - I'm confused. The
code in any given branch of a 'constexpr if' statement only has to be
valid in the event that the branch is taken. That's most of the point.
As an example, if you have constexpr if (std::is_trivial<the_type>), and
that branch performs operations which are only valid on trivial types,
there are no issues to the best of my knowledge (and experience). Where
is this wrong?
* "Opt-in UB on Unsigned Overflow" = more info on this and how it could
present performance gains would be good.
Cheers,
Matt

ps. Might be worth posting this on reddit/cpp or similar once done, I'm
sure I'm not the only one with an opinion on the subject.


On 5/10/2021 10:14 am, Patrice Roy wrote:
> I will but did not since. I have collected a lot of information
> (valuable information, at that) through many of you and some of the
> initial contributors, I just did not find the time to put it together
> yet. Will do ASAP.
>
> Le lun. 4 oct. 2021 à 04:05, Matt Bentley <mattreecebentley_at_[hidden]
> <mailto:mattreecebentley_at_[hidden]>> a écrit :
>
> On 11/09/2021 4:19 am, Patrice Roy wrote:
> > Noted; I'll find a way to put in in the document, v2 that I hope
> to send
> > next week, so please verify that I communicated your thoughts
> properly
> > when you get it. Thanks Matt!
>
> Just to follow up, did you get anywhere with this Patrice?
>
>
>
>
>
> On 12/09/2021 12:34 am, Patrice Roy wrote:
> > Small personal note : I don't think a switch to turn constexpr
> off alone
> > can work, as constexpr kicks in with constexpr contexts :
> >
> > unsigned long long factorial(int n) {
> > return n == 0? 1ULL : n * factorial(n-1);
> > }
> > int main() {
> > float arr[factorial(5)]{}; // array of 120 float all
> initialized
> to 0.0f
> > return factorial(5); // runtime function call
> > }
> >
> > We can debug with the runtime call, but if we turned constexpr
> off the
> > whole program would stop compiling due to arr.
> >
> > If you think we need a mechanism to selectively disable
> constexpr, I can
> > add it to the document but we'd need to define the intent more
> clearly.
>
>
> I think just something which ignores the constexpr on functions and
> always runs them at runtime, is all that's likely to be needed, if I'm
> right about it becoming a performance problem (and I could be wrong if
> the compilers get smart about when they're resolving at compile time vs
> runtime).
> But obviously stuff like "constexpr if" cannot be switched off as the
> non-called branch may create invalid code depending on the arguments of
> the if statement.
>