At Meeting C++ 2017 — which was great, BTW — I attended a talk by Guy Davidson about the C++ graphics 2D proposal, wording here.

Now, there is some controversy about the proposal — especially by those who do serious graphics stuff. Does the C++ standard library need 2D graphics? Shouldn’t the committee focus on real issues instead of some toy library that is never going to be used for serious applications?

But I’m not here to rant about the stupid standard committee and the completely bloated and unusable standard library, like some do. Instead, this discussion got me thinking: What should be part of a language’s standard library?

Implicit conversions considered harmful.

Okay, this might be a little harsh:

Potentially dangerous and/or expensive implicit conversions considered harmful.

Better.

Implicit conversions will happen “accidentally” by their very nature, so if they happen, they should always do the right thing.

And how to prevent implicit conversions? Simple: use an explicit constructor.

But that’s only half of the problem: What about assignment? Is there explicit assignment? If so, when do I use it?

C++11 introduced move semantics. With it, you can encode transfer of ownership and allow to put types in a container where you can’t copy them.

This clearly is powerful.

But the current move system isn’t perfect, there are a couple of issues. There is an arguably cleaner approach: destructive move.

In this post we’ll explore a purely theoretical alternative C++ with destructive move.

A discussion on Twitter got me thinking about operator precedence. It is a crucial part of most programming languages as it dictates the meaning of expressions.

Interestingly enough, it is practically the same in almost all programming languages, even ones that radical try to be a better alternative for an established language. So apparently operator precedence is a solved problem, right?

Well, I don’t think so. I think operator precedence is fundamentally flawed and could easily be improved.

Sometimes you’re lazy. You know you need to do something, but don’t want to do it yet. You don’t need to do it right now, only at some later point. And maybe later it turns out that you don’t need to do the entire work, just a part of it or nothing at all! So if you’re eager and do it right now, you might do more work than needed.

The same applies to your code. Sometimes you do things even though it is not necessary. You call a function passing it some arguments that were expensive to calculate and then the function don’t need all of them due to some other arguments. Wouldn’t it be great to only calculate the arguments when they are actually needed?

This is called lazy evaluation of function arguments and this blog post presents how it can be done in C++.