Skip to content

Conversation

@Bodigrim
Copy link
Contributor

Copy link
Member

@sjakobi sjakobi left a comment

Choose a reason for hiding this comment

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

How does this affect performance? I imagine it wouldn't be too bad.

@Bodigrim
Copy link
Contributor Author

As https://mail.haskell.org/pipermail/libraries/2021-May/031246.html explains, adding HasCallStack to non-recursive functions, which are likely to inline, should not impose additional performance costs. We also provide Data.ByteString.Unsafe, which should be used in performance-critical setting.

@Bodigrim
Copy link
Contributor Author

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

@sjakobi
Copy link
Member

sjakobi commented Nov 17, 2021

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

🤷

@phadej, what do you think?

@Bodigrim
Copy link
Contributor Author

On the other hand, it's equivalent to changing error messages, which I would not qualify as a breakage...

@sjakobi
Copy link
Member

sjakobi commented Nov 22, 2021

I wonder whether addition of HasCallStack requires a major version bump. It cannot break anything, however there could be clients who catch error in IO and analyse error message.

Are you sure that it won't break anything? It reminds me of haskell/cabal#6545, where some code involving HasCallStack required changes due to simplified subsumption. I'm wondering whether adding HasCallStack constraints might also require changes on the user side.

@Bodigrim
Copy link
Contributor Author

@phadej
Copy link
Contributor

phadej commented Nov 23, 2021

#6545 is not due HasCallStack itself but due

type IO a = HasCallStack => Base.IO a

which is rank2 type-alias. And that's what was affected by simplified subsumption.

@sjakobi
Copy link
Member

sjakobi commented Nov 27, 2021

I'm fine with treating this as a non-breaking change, i.e. releasing this in 0.11.x.

@Bodigrim Bodigrim added this to the 0.11.2.0 milestone Nov 27, 2021
@Bodigrim Bodigrim merged commit 963d625 into haskell:master Nov 27, 2021
@Bodigrim Bodigrim deleted the hascallstack branch November 27, 2021 12:08
Bodigrim added a commit to Bodigrim/bytestring that referenced this pull request Dec 4, 2021
noughtmare pushed a commit to noughtmare/bytestring that referenced this pull request Dec 12, 2021
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

Successfully merging this pull request may close these issues.

3 participants