Very interesting presentation with lots of useful insight. I will probably watch this again to make sure I soak it all up.

Hi, Niall.
I really enjoyed your talk. I always enjoy hearing about specific implementations of new features in languages; sometimes just reading the "what's new" of code standard doesn't always help in understanding where/why/how you might use the new feature. And, in the case of your presentation, it's really distilled down ways to use some parts of C++ when moving from C.
Like Oliver, I miss a lot of C++ features that I used to use (in embedded programming) because my current employer only uses C. While I've advocated for moving to C++ long-term, it's not a language that most of the engineers here know. So I'm hoping that maybe I can use this presentation to help me help them make the transition more easily. ...or at least consider the transition!

Hi, thank you for the interesting talk. I really enjoyed listening to you.
When I started my last C-Project I was wondering if I should use C++ or C. I took C because the Libraries of my uC were written in that language.

I am missing lots of C++ features though and I think I might try your C+ approach (I didn't hear that term before). I am always crying that I can't use overloading of functions and I like the Idea behind the if-init structure you showed.

There is one thing I was stumbling over and I don't know if I'm just to stupid/ignorant to understand the usefulness. I'm still not convinced about the "auto" statement.

For me one of the best features of C and C++ is the type safety of the type system. I think it prevents lots of bugs, because I have to think about what I am doing and what type fits my cause. For me the auto feature takes away that safety net and I think your examples show the danger instead of the robustness.

This should be the code from slide 19 (please add slide numbers on your next presentation :-) )

std::uint8_t values[] = {1,2,3};
init main() {
for (auto v : values) {
printf("%u\n", v);
}
}

If I got you right you say in the example I can change my variables from 8 to 16 bit and I will not break the code while doing that. That ist why robustness is increased.

But my problem is, if I don't check the whole code I will not see that I can't use double or even int8_t without breaking my functionality. How does that fit the promise of robustness?

I understand that auto helps increasing readability on the side that it takes away clutter and lets me see the real purpose of my code. Especially in C++ that is very useful, because the types can become very long. I still think it is dangerous, because I might misinterpret what the compiler is doing.

In your example with the if-init construct (slide 25) could I use the following:
using PairOptional = std::optional;
if(ReturnedTwoDoubles result = solve_quadratic(1.0, 5.0, 6.0)){}

instead of the original line?
if(auto result = solve_quadratic(1.0, 5.0, 6.0)){}

Would you see that as a good solution or is it just a bad idea?

Thanks again for your talk, It was fun thinking about your solutions.