Use a package trait for typed throws?

[stephentyrone]

@florianpircher asks: Is it possible to surface typed throws using a package trait instead of checking for the embedded mode?

[florianpircher]

I mention this in reference to

This has the benefit of keeping the simplicity of untyped errors in non-embedded code, but means that adopting code can't choose to use explicitly typed errors when in non-embedded mode.

from #5.

I am not very familiar with package traits yet and I didn’t know about #if !$Embedded before reading the pull request, so maybe I am missing something. Maybe the trait default could be set using !$Embedded such that it just works when working with embedded systems without having to set a trait manually.

---

I am also not sure about

This has the benefit of keeping the simplicity of untyped errors in non-embedded code

What would be the downside of always using typed errors? As far as I understand, the library needs to handle typed errors anyway for embedded and consumers of the library can ignore the error type if they are not interested.

[natecook1000]

The issue for these functions is that they take a user-supplied throwing closure, but can also throw their own errors, so the function can't have its overall error type be either the closure's error type or the library's currency error type. I'm still looking at a couple alternative approaches here.

Package traits look like an interesting approach to providing this flexibility for users! I haven't used them before either, so I'll take a look at how they could apply.

[florianpircher]

Makes sense with mixing user errors and library errors being difficult. Thanks for explaining and thanks for the great WWDC session!

[natecook1000]

@florianpircher I think the change in #10 should address this without needing a package trait. There will always be a ParsingError-typed version of these parsing initializers available, with an additional untyped throws version available in non-embedded contexts.

[florianpircher]

Yes, I think that resolves it. I didn’t create this issue, so I cannot close it myself.

Interesting use of overloads for typed and untyped functions; I’ll have to try that in my own code some time.

[stephentyrone]

Thanks, @florianpircher. I'm going to close this issue.