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

Remove/deprecate inPlaceBroken port types? #94

Open
prokopyl opened this issue Aug 2, 2021 · 1 comment
Open

Remove/deprecate inPlaceBroken port types? #94

prokopyl opened this issue Aug 2, 2021 · 1 comment
Labels
💔 Breaking change Changes to the code that will lead to break one or more APIs 🗨️ Discussion An exchange of opinions about a topic 🌟 Ergonomics Little things that matter! Does not add functionality, but makes an API easier to use

Comments

@prokopyl
Copy link
Member

prokopyl commented Aug 2, 2021

I am making this issue to separate the conversation about the implementation in #93, and the following questions that were raised:

  • Should the in-place-compatible port types be the default?
  • Should in-place-broken processing be supported at all?

There was already a rather large conversation and many points that were stated in the discussion thread in #93 which I won't reproduce here.

Considering this change, if implemented, would not be done until after the next major release (since it would be breaking), discussing it can wait, while restoring compatibility with hosts that do not allow inPlaceBroken (see #89) is more pressing. 🙂

@prokopyl prokopyl added 🗨️ Discussion An exchange of opinions about a topic 💔 Breaking change Changes to the code that will lead to break one or more APIs labels Aug 2, 2021
@prokopyl prokopyl added the 🌟 Ergonomics Little things that matter! Does not add functionality, but makes an API easier to use label Aug 9, 2021
@PieterPenninckx
Copy link
Contributor

Should the in-place-compatible port types be the default?

I think it's best to not have a "default" that can be overridden, but to just always "ask to choose". The documentation should promote the in-place-compatible port types, in my opinion (otherwise there will be too many questions about non-supported hosts).

Should in-place-broken processing be supported at all?

I don't think there are that many use cases for it. I would replace it by something more low-level and unsafe (i.e.: exposing the raw pointers).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💔 Breaking change Changes to the code that will lead to break one or more APIs 🗨️ Discussion An exchange of opinions about a topic 🌟 Ergonomics Little things that matter! Does not add functionality, but makes an API easier to use
Projects
None yet
Development

No branches or pull requests

2 participants