This repository has been archived by the owner on Jun 24, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 369
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(llm): require errors to be Send+Sync
- Loading branch information
Showing
1 changed file
with
14 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
74d2d67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brilliant, this was biting me the other day 👍
74d2d67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it bit me a few times - I was trying to avoid it because I didn't want to require all errors to be Send+Sync, but I didn't want to deal with the headache of trying to genericise the error over Send/Sync. We'll see if anyone complains 😅
74d2d67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I think it is not uncommon for error types to be Send+Sync anyway. They should be lightweight objects anyway, either simple enums/constant strings, or allocated anew for each error (with specific error information). Send is easy to achieve and Sync is no issue for an object that isn't really shared anyway.
74d2d67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the only concern I have is single-threaded environments where the traits aren't relevant/can't be implemented (i.e. WASM). That's a bridge we can cross when we get to it.