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 assuming the minimum semantics that the library requires (Always Spaceship) There isn’t really that much to say about Never Spaceship. This post will focus on Sometimes Spaceship — how to conditionally provide spaceship. Always Spaceship will be the subject of a future post (I’m using “Always” here to still be conditioned on the type having comparison operators — I’m not suggesting that you take a type without any comparisons defined, stick it in a vector and suddenly you can compare them).

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 topic in an earlier post on CTAD quirks, and I wanted to write some words about the latter topic here — since I think it’s really interesting.

This post is a response to RangeOf: A better span, which has many problems worth addressing in detail. While most of this post will deal with specifically std::span<T> (which is indeed the best span), the last section will also discuss a recent addition to the standard library: std::ranges::subrange<T*>. Read the rest at: span: the best span Barry's C++ Blogbrevzin.github.io

Last week, the C++ Standards Committee met in San Diego to work on C++20. One of my own main goals was to discuss two papers I wrote making improvements to a new language feature for C++20: operator <=>, also known as the three-way comparison operator but better known as the spaceship operator. There were two serious problems with spaceship that I set out to address: performance and usability. I wanted to take the time to describe the problems I’m trying to solve, my solutions to them, what the committee thought about both, and what could happen in the future.

I’m actually transitioning my blog over to Jekyll and github-pages. It’s actually very tedious to write code examples on Medium due to it not having a direct syntax-highlighting mechanism. The new post is: Declarations using Concepts Barry's C++ Blogbrevzin.github.io Let me know what you think of the new layout vs Medium, and for those of you that follow, subscribe via RSS! Thanks for reading.

… in C++. Update: I’m transitioning off of Medium, and have reposted this story onto my new blog, which can be found here. Thanks for reading! That seems like a fundamentally wrong statement to make right? C++ has been greatly improving over the last few standards in its direct support…

Update: I’m transitioning off of Medium, and have reposted this story onto my new blog, which can be found here. Thanks for reading! Before C++17, template deduction [basically] worked in two situations: deduction function parameters in function templates and deducing auto for variables/return types in functions. …

Jonathan Müller recently wrote a blog post arguing (among other things) that we don’t need optional<T&>, making the points that: For function parameters, overloading works better For returning an object that may or may not exist, return a T* instead I would like here to argue against those points —…

In my last post, I talked about the concept of Westie types (yes, I am trying to make this happen), what Regular means, and which of them are Regular. I went through an explanation for why means for span is not Regular and potentially why it should be. …