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

errors: new Unwrap and As funcs do not expose interfaces #35306

Open
epelc opened this issue Nov 1, 2019 · 4 comments
Open

errors: new Unwrap and As funcs do not expose interfaces #35306

epelc opened this issue Nov 1, 2019 · 4 comments

Comments

@epelc
Copy link

@epelc epelc commented Nov 1, 2019

Is there a reason why the new Unwrap and As functions in the errors package do not expose interfaces for the methods they require to be implemented. I understand that you would not change their signature to accept these interfaces but I believe the Unwrapper and As anonymous interfaces should be named and exported. Their methods are already apart of the go 1.x api compat so why not expose them fully and make the docs easier to read?

The trend of saying such and such func expects your type implement some method doesn't seem like a good one to go down. It makes it harder for new users to figured things out without reading source code or hoping they got the signature exactly correct from an english description of it. I don't believe this pattern has been used anywhere else in the std lib to my knowledge.

Example errors.Unwrap uses anonymous interface https://golang.org/src/errors/wrap.go?s=372:400#L4

@ianlancetaylor ianlancetaylor changed the title New error Unwrap and As funcs do not expose interfaces errors: new Unwrap and As funcs do not expose interfaces Nov 1, 2019
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 1, 2019

@neild
Copy link
Contributor

@neild neild commented Nov 1, 2019

We originally had an errors.Wrapper interface definition:

type Wrapper interface {
  Unwrap() error
}

There was substantial debate over whether this type should be called Wrapper (since a Wrapper wraps another error) or Unwrapper (since an Unwrapper has an Unwrap method). In the end, we removed the Unwrapper type on the grounds that we could add it later when we had more clarity on the best name for it.

We considered errors.Iser and errors.Aser types:

type Iser interface {
  Is(error) bool
}

type Aser interface {
  As(interface{}) bool
}

My recollection is that we didn't like the names and couldn't think of many, if any, cases when you would use the Iser and Aser types directly.

@epelc
Copy link
Author

@epelc epelc commented Nov 1, 2019

@neild Thanks! Good to know it was on the grounds of not having a good name instead of wanting to not expose these.

Hopefully this issue serves as some docs until something is eventually picked.

@FiloSottile FiloSottile added this to the Unplanned milestone Nov 5, 2019
@as
Copy link
Contributor

@as as commented Nov 7, 2019

A named interface is more-constrained than an anonymous interface, as comparisons are currently taking the name of the type into account with a named interface.

How will this impact the proposal?

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

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.