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

lang: add E type argument to Result type alias #2731

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mina86
Copy link
Contributor

@mina86 mina86 commented Dec 13, 2023

Considering that Result is included in Anchor’s prelude, it’s quite
annoying when one suddenly needs to use Result with a different error
than Anchor’s Error (i.e. use the symbol Result like the actual Rust
Result type).

Add E type argument to Anchar’s Result type-alias so that the symbol
can continue to be used like in any Rust code even when someone
imports Anchor’s prelude.

Specify E’s default value to Anchor’s Error so existing Anchor-based
code can continue using the alias as before.

Considering that Result is included in Anchor’s prelude, it’s quite
annoying when one suddenly needs to use Result with a different error
than Anchor’s Error (i.e. use the symbol `Result` like the actual Rust
Result type).

Add E type argument to Anchar’s Result type-alias so that the symbol
can continue to be used like in any Rust code even when someone
imports Anchor’s prelude.

Specify E’s default value to Anchor’s Error so existing Anchor-based
code can continue using the alias as before.
Copy link

vercel bot commented Dec 13, 2023

@mina86 is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

Copy link
Collaborator

@acheroncrypto acheroncrypto left a comment

Choose a reason for hiding this comment

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

A pre-defined error type is preferred for libraries e.g. syn::Result and std::io::Result.

To me, having generic errors only makes sense if the project is:

  • A generic error library like anyhow
  • An application

@mina86
Copy link
Contributor Author

mina86 commented Dec 18, 2023

The problem is that Anchor’s Result is in prelude and importing everything in prelude is recommended way to write Anchor programs (in fact some Anchor macros require it IIRC). The difference with syn::Result or std::io::Result is that if I do use std::io::Result I consciously chose to use io’s Result. If Anchor had no prelude, the current approach wouldn’t be an issue. Anchor’s prelude shadowing a standard library type is the issue.

@acheroncrypto
Copy link
Collaborator

Yeah, I generally agree with overriding the default Result by importing the prelude can be annoying but given the fix for when you want to return a different error type is easy enough(1 line of code), I don't currently think we need to support generic error types from Anchor's Result. Having a known error type can be useful.

@mina86
Copy link
Contributor Author

mina86 commented Dec 18, 2023

I don’t understand what you mean by ‘having a known error type’. With my proposed change the error type would still be known.

@acheroncrypto
Copy link
Collaborator

By "having a known error type" I mean having Anchor's Error type when using Anchor's Result type.

@mina86
Copy link
Contributor Author

mina86 commented Dec 18, 2023

When you write Result<T> you still have Anchor’s Error type. Nothing changes on that front.

@acheroncrypto
Copy link
Collaborator

I'm aware.

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

Successfully merging this pull request may close these issues.

None yet

2 participants