Niall,

For now, I’m looking at some rate helpers (AverageOISRateHelper, CrossCcyBasisSwapHelper, OIBSHelper, OICCBSHelper, OISRateHelper, TenorBasisSwapHelper), their associated instruments & engines (and whatever needs to be transferred to properly compile really) & some indexes (although I could use IborIndex for everything).
I’m at the early days of building a wrapper in C# to construct various curves, and I hope to move on to volatility surfaces in the future, so this list is by no means set in stone and is bound to grow.

I most definitely understand the reasons why you build QuantExt outside of QuantLib. Not being tied to the QuantLib release cycle, avoiding conflicts and dependencies, and some more specific extensions around market simulation models being less suited to be in QuantLib are all fair points.
However I would be partisan for as much of the QuantExt functionalities as possible to be transferred to QuantLib for the following reasons (some might be a bit self centered, my apologies):
– The already existing QuantLib-SWIG project I mention in my previous post,
– Duplication of functionality: back in the days when you released ORE, I was contributing to QuantLib some AUD BBSW indexes. I saw that you had them to in QuantExt after contributing them. Ideally, one set should go away, however while adding classes is easy, removing them after they start being used is much harder I’m sure you’ll agree.
– Duplication of work: work has been done in QuantLib to enable VS2017. I don’t think it has been done in QuantExt yet, and it would consist of pretty much the same tasks.
– Extended peer review: I found a compilation error in QuantExt when using a modified userconfig.hpp, which I’m sure the (wider?) QuantLib community would have spotted and corrected much earlier.
– Currently the Engine repository points to commit fed85cc of QuantLib (20/09/2016). For this and some of the reasons above, I have QuantExt refer to my own clone of QuantLib, not the one provided in the ORE repository. I’m not familiar with Git submodules, but it seems to put the effort of keeping QuantLib updated on you, which has pros (out of the box ORE) and cons (old QuantLib version).

It’s a bit of a mishmash, and not all those issues would be completely solved by transferring the functionalities I’m looking at to QuantLib. However I do believe there is a case for most “natural” (whatever that means) classes to be transferred over.

Note I intend to contribute fixes to ORE for points 3 & 4 above in the near future.

Regards,
Fabrice