Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should QuantLib hard deprecations of daycounters be respected by RQuantLib #168

Open
klin333 opened this issue Mar 16, 2022 · 2 comments
Open

Comments

@klin333
Copy link
Contributor

klin333 commented Mar 16, 2022

QL 1.23 hard deprecated ActualActual with no explicit convention argument, but in RQuantLib we only soft deprecate Enum 2, by explicitly passing in the same default convention. Do we want to respect this deprecation in RQuantLib and force users to select enums 8-13. Similarly with Thirty360.

Currently it is

rquantlib/src/utils.cpp

Lines 370 to 371 in 57846cb

else if (n==2)
return QuantLib::ActualActual(QuantLib::ActualActual::ISDA); // reasonable default for back compatibility

Should we make it:

#if QL_HEX_VERSION < 0x012300f0
    else if (n==2)
        return QuantLib::ActualActual();
#endif

I'm personally supportive of leaving things in RQuantLib as it is, ie only soft deprecate. But we should collectively determine how far we want to take the strategy of 'bug for bug, feature for feature' between RQuantLib and QuantLib.

@eddelbuettel
Copy link
Owner

Good question. That QL itself deprecated something gives us a strong hint to also remove it (maybe after some time). Then again there is no point in making life harder for users so if it isn't in the way or use up any resources ... we can maybe just leave it?

@klin333
Copy link
Contributor Author

klin333 commented Mar 16, 2022

I'm happy to leave it unless some rquantlib user realises some problems otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants