Welcome back.

I’ve never been one for plans, so I probably have no business writing a post on what we might expect from QuantLib in the next year or two—especially since it’s driven by contributions by volunteers. Yet, here we are. In this post, I’ll list a few things I’ll try to work on, or that I’d be happy for enterprising people to pick up.

New risk-free rates

The first one is kind of obvious, and in fact, there’s already been some discussion on the QuantLib mailing list about this. We should cover instruments paying the SOFR, ESTR and friends, which we kind of support but not explicitly. We have classes such as OvernightIndexedCoupon, which compounds overnight fixings over the life of the coupon, or OvernightIndexFutures, which currently acquired the ability to perform averaging as well as compounding, as required by 1-month SOFR futures. However, we should probably reorganize and abstract out the code that performs the averaging and/or the compounding, so that it can be reused across instruments. It might be a set of functions or some class, depending on how we choose to model it. If you want to have a shot at it, by all means open a pull request.

Inflation-based instruments

After using it for a while, a few things in the current implementation of inflation rates have started to seriously irk me (I had noted some of them already in Implementing QuantLib.

One is the fact that inflation term structures take a discount curve as a constructor argument. I started to do something about this by passing the discount curve to the relevant pricing engines instead (so they can stop relying on the one in the inflation term structure) and deprecating their other constructors. Once they are removed, probably in version 1.19, we can start doing the same to the inflation term structures. Unfortunately, it’s going to be slow work due to backward compatibility.

More irksome, though, is the existence of two separate ZeroInflationIndex and YoYInflationIndex classes. I agree that we might need different classes to forecast zero rates and year-on-year rates, but there’s no such thing as a year-on-year HICP index; there are instruments that pay the year-on-year performance of the HICP index, and that performance is not an index fixing in itself. We should have just one index hierarchy.

By the same reasoning, there is no interpolated HICP index as opposed to a non-interpolated one. That index fixes monthly; different instruments might calculate their payoff by interpolating between fixings, and they should not delegate the calculation to the index itself (which, in the current implementation, delegates it in turn to the underlying term structure, making it even worse).

(A note: I’m definitely not meaning to disparage whoever wrote that code. It was 10 or 15 years ago, the architecture at that time was not clear, and they—we, since I probably had a hand in that— did the best they could. But now that we know better, I’d like to change the code to reflect the new understanding.)


I’ve written a bunch of posts about my experiments with leaving C++03, and given that C++20 was recently approved, it might be time do to something about it and adopt at least C++11. The one thing holding us back is compiler compatibility; we’ll need to require at least Visual Studio 2015 to have decent language support, so it will take a few versions to deprecate and drop support for earlier versions. QuantLib 1.17 deprecated VS 2010; later releases will deprecate VS 2012 and 2013, but it will probably take a year or two before we do the jump.

Once we do that, we’ll probably switch from some Boost classes we’re using (such as shared_ptr or function) to the corresponding std classes—which, by the way, is already possible if you choose to do so. At that point, it might be worth determining what other Boost code we use, and if there’s any possibility of removing the dependency on Boost altogether.


This is an old one; I wrote about it in Implementing QuantLib when I described the global Settings class, and before that I talked about it at the QuantLib User Meeting in 2013, so I’ll put it very shortly here. I’d like to replace the existing globals, but I don’t have yet an idea of how to do it. I’ll be grateful for any suggestion.

Libor Market Model

I’ll be frank: I would see this as a kind of tribute to Mark Joshi, who passed away in 2017 and who led the effort of writing our current implementation of the LMM model. That part of the library still needs to be brought together with the rest of the architecture by providing the means to use it in pricing engines. I’d love for that to happen.

Anything else

The above is just a list of a few things I’d like to see; and of course, I’m probably overlooking other stuff, and I’ll be as happy and as grateful as usual to accept other contributions. You’ve been great during these past 20 years, and I’m sure you’ll keep being great during the years to come.

Follow me on Twitter if you want to be notified of new posts, or subscribe via RSS: the buttons for that are in the footer. Also, I’m available for training, both online and (when possible) on-site: visit my Training page for more information.