Skip to content

Use enums/More explicit types #258

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 12 commits into from
May 14, 2019
Merged

Use enums/More explicit types #258

merged 12 commits into from
May 14, 2019

Conversation

minad
Copy link
Member

@minad minad commented May 13, 2019

  • Makes the API more obvious
  • Allows us to catch a few implicit conversions
  • 100% API/ABI backwards compatible

@minad minad force-pushed the more-explicit-types branch 2 times, most recently from 72089c5 to 7d3d34d Compare May 13, 2019 09:12
@minad minad changed the title More explicit types Use enums/More explicit types May 13, 2019
@minad minad mentioned this pull request May 13, 2019
Merged
@minad minad requested review from sjaeckel, nijtmans and czurnieden May 13, 2019 09:38
czurnieden
czurnieden approved these changes May 13, 2019
View reviewed changes
Copy link
Contributor

@czurnieden czurnieden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MP_RANGE is not used in LTM and should either go or get its own value. Both would get rid of the necessity to number all entries explicitly instead of just the first one but also kills your promise of "100% API/ABI backwards compatible"

But otherwise…

@minad
Copy link
Member Author

minad commented May 13, 2019

@czurnieden We could just remove MP_RANGE from the enum. Defining MP_USE_ENUM somehow selects the "modernised" API. Furthermore I will make MP_RANGE deprecated then.

@minad minad force-pushed the more-explicit-types branch from 2f78b4a to 6f4952a Compare May 13, 2019 16:12
nijtmans
nijtmans previously requested changes May 13, 2019
View reviewed changes
Copy link
Collaborator

@nijtmans nijtmans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MP_FREE_BUFFER can be improved, see comment there

@minad minad mentioned this pull request May 13, 2019
Merged
@minad minad requested a review from nijtmans May 13, 2019 17:08
@minad minad dismissed nijtmans’s stale review May 13, 2019 17:09

does not apply to this PR but to #255

minad added 5 commits May 13, 2019 19:15
@minad
use enums mp_err, mp_ord, mp_bool, mp_sign
4534056 
* MP_USE_ENUMS enables enums
* Wc++-compat catches some implicit conversions if MP_USE_ENUMS is defined
* 100% backwards compatible API/ABI if MP_USE_ENUMS is not defined
@minad
MP_FREE_DIGITS: add missing cast
0b73dab
@minad
deprecate MP_RANGE
89bac3a
@minad
fix signature
334c32e
@minad
remove unnecessary duplication of multiplication
668cda0
@minad minad force-pushed the more-explicit-types branch from 6f4952a to 668cda0 Compare May 13, 2019 17:20
@minad minad removed the request for review from nijtmans May 13, 2019 17:32
@nijtmans nijtmans self-requested a review May 13, 2019 19:35
@minad
Copy link
Member Author

minad commented May 13, 2019

Thx @nijtmans!

sjaeckel
sjaeckel approved these changes May 14, 2019
View reviewed changes
Copy link
Member

@sjaeckel sjaeckel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you did now what I struggled with for a long time... I'm still not sure if I prefer a generic int as return value or an enum... but I like it now that it's there

also I appreciate that @fperrad immediately linted the PR, I like that way a lot better and IMO we could keep doing this approach :-)

@sjaeckel
Copy link
Member

also I appreciate that @fperrad immediately linted the PR, I like that way a lot better and IMO we could keep doing this approach :-)

ah lol, @minad simply rebased on top of #259 also fine by me, but @fperrad how about doing this for future PR's? as soon as they're good to go you put your linting commits on top

@sjaeckel sjaeckel merged commit 4b334b4 into develop May 14, 2019
@sjaeckel sjaeckel deleted the more-explicit-types branch May 14, 2019 07:27
@minad minad mentioned this pull request May 27, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sjaeckel sjaeckel sjaeckel approved these changes

@czurnieden czurnieden czurnieden approved these changes

@nijtmans nijtmans nijtmans approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@minad @sjaeckel @czurnieden @nijtmans @fperrad