Like many open source developers I use GitHub to publish my work. It comes with a built-in issue tracking system, however, it isn’t that great.

The main issue - no pun intended - I have with it is that there is not an easy way to see all open issues and pull requests on all repositories you have. There is the issue workspace, but it only shows issues I’ve created, where I’m mentioned, or I’m assigned to. This isn’t helpful in my case, so I’ve looked for a different solution. There are also so-called “Projects”, but they are just for one repository - I need one for all.

I finally found a solution: It uses Trello and If This Then That.

A while back — but sadly not too many blog posts ago — I wrote about explicit constructors and how to handle assignment. In this blog post, I made the assumption that you most likely want to have explicit single argument constructors.

But when do we actually want implicit single argument constructors?

Let’s consider the broader question: How should I design a cast operation for my user-defined type? And how should I design a constructor?

But first, something different: what is the difference between a cast and a constructor?

C++ as a language is moving away from the classical, “Java style”, object-oriented programming. Long gone are the days of grand, virtual hierarchies. They’ve been replaced with standalone classes, free functions and type erasure.

And the benefits are clear: Instead of reference semantics, they allow value semantics which are simpler and more natural for C++. Instead of intrusive interface inheritance, they allow external duck-typing.

So in the spirit of this movement, let’s take a look at one OOP pattern and see if we can adopt it to this style: the visitor pattern.

This isn’t the blog post I wanted to publish today, this is the blog post I had to publish.

Simon blogged about using ADTs for error handling, leading to an interesting reddit discussion. Then Vittorio wanted to share his thoughts on the matter, leading to an even bigger reddit discussion. Now I’d like to chime in and offer a reasonable solution.

It is the age-old question: return codes vs exceptions. But this time, return codes have gotten an upgrade: std::expected and similar types.

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?