I don't follow the logic of avoiding error types. If I'm calling `foo.Bar()` directly, I already have a direct dependency on package `foo`, so what difference

I don't follow the logic of avoiding error types. If I'm calling `foo.Bar()` directly, I already have a direct dependency on package `foo`, so what difference does it make to have another one to get `foo.BarError`? If I'm calling `foo.Bar()` indirectly, then it's true that checking `foo.ErrorType` introduces a novel dependency upon `foo`, but it's equally true that: a) my direct dependency is frequently going to check and wrap that error in some other type anyway, and b) I can still use the interface trick that Dave describes to avoid a dependency on `foo`. I don't see why forcing callers to declare helper interfaces every single time they want to inspect an error is preferable to them only having to do that as a rare workaround.