In my previous post on the topic, I went through all the proposals we’ve had that were in the general space of unified function call syntax. That is, anything in which member function syntax might find a non-member function or non-member syntax might find a member function - with multiple sets of...
This post describes a particular software lifetime issue I run into a lot, and a solution I use for it that I’m not particularly fond of. I’m writing this post in the hope that other people have run into the same issues and either have better ideas about how to solve it now, or better ideas of ho...
Now that the Cologne meeting is over and we’ve more or less finalized (at least before the NB comments come in) C++20, I wanted to take the time to describe in detail one of the new language features we can look forward to. The feature is typically referred to as operator<=> (defined in the...
One of the language proposals in the last few years that comes up fairly regularly is Unified Function Call Syntax, sometimes also called Unified Call Syntax. I’m going to use the former name, abbreviated as UFCS, because FLAs are the new TLAs. What makes this particular proposal confusing in th...
A few months ago, I wrote a post with some motivating examples, and I just wanted to add some more to the list. RangeOf Sometimes, we want to write an algorithm that takes a range of some specific type. Say, we want to operate specifically over ints. We can do that: template <typename R, ty...
Andrei Alexandrescu’s Meeting C++ Keynote The Next Big Thing was just posted recently on YouTube. I am a big fan of Andrei on a number of levels - he is very much my idol. This last talk that he gave was about the limitations of if constexpr as compared to “another language” and how C++ should do...
I thought I’d take a break from writing about <=> and talk instead about Concepts. One of the things you cannot do with Concepts is use them as template parameters. Which means that you cannot compose concepts in any way except strictly using && or ||. This still gets a lot of good ...
In my previous post, I demonstrated how to provide operator<=> for a class template conditioned on whether its underlying type provided operator<=> (i.e. Sometimes Spaceship). The key insight there was to ensure that <=> is more constrained than each of <, >, <=, and &g...
When it comes to adopting operator<=> for library class templates, there are three choices a library can make: Just don’t adopt it (Never Spaceship) Conditionally adopt it if all of its constituent types provide it (Sometimes Spaceship) Unconditionally adopt it, if necessary assumi...
Andrzej has a great new post about the difficulty that arises when the language or the library tries to make assumptions about programmer intent. He brings up two examples of this difficulty: should CTAD wrap or copy? how should optional’s mixed comparison behave? I’ve touched on the first...