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

drop max_fixed_size since it becomes part of the ABI? #38

Closed
mattkretz opened this Issue Feb 28, 2017 · 1 comment

Comments

1 participant
@mattkretz
Copy link
Owner

mattkretz commented Feb 28, 2017

datapar_abi::max_fixed_size: Why would that be an ABI break?

Because the number becomes part of the ABI. I.e. I could use the value to instantiate fixed_size_datapar<int, max_fixed_size> and get a different type should an implementation want to change the value.

If we consider changes to the value of max_fixed_size an ABI break, then having this number forces implementations to choose a value for their first release and stick with it forever.

Options:

  1. Keep the constant (no change to the paper). Maybe add a note about ABI?
  2. Drop the constant. Do we then expect implementations to document the value? I guess it's still discoverable via SFINAE: the smallest N for which fixed_size_datapar<T, N> results in a substitution failure implies that max_fixed_size = N - 1.
@mattkretz

This comment has been minimized.

Copy link
Owner

mattkretz commented Mar 6, 2017

The next paper revision needs to answer/discuss the following:

  • Why a single value for max_fixed_size, why not dependent on T? Shouldn't it be a variable template?
  • Should max_fixed_size (or some other wording) ensure that widening from a native 8-bit integer to 64-bit long/double fixed_size works?
  • The value should stay there. Users will misuse the fixed_size feature otherwise.
  • Some note should encourage implementations to change the value even if it may introduce an ABI break. Users are skating on thin ice if they build types from the value.

@mattkretz mattkretz added this to Awaiting Feedback in P0214R4 Mar 8, 2017

@mattkretz mattkretz moved this from Awaiting Feedback to Backlog in P0214R4 Jun 12, 2017

@mattkretz mattkretz moved this from Backlog to In Progress in P0214R4 Jun 12, 2017

@mattkretz mattkretz closed this Jun 14, 2017

@mattkretz mattkretz moved this from In Progress to Review in P0214R4 Jun 14, 2017

@mattkretz mattkretz moved this from LWG Review to LEWG Review in P0214R4 Jun 14, 2017

@mattkretz mattkretz moved this from LEWG Review to Done in P0214R4 Mar 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment