Stream: ideas

Topic: variant errors; can I handle non-thrown errors?

drathier (Aug 12 2023 at 15:24):

Hey, does Roc have any scoping on the variant error types? In Purescript VexceptT, it's possible to write code that handles error tags that are never constructed. Thus you end up with unreachable error handling code as you add/remove errors over time. Does Roc guard against that happening? Should it? Can it?

drathier (Aug 12 2023 at 15:24):

Hey, does Roc have any scoping on the variant error types? In Purescript VexceptT, it's possible to write code that handles error tags that are never constructed. Thus you end up with unreachable error handling code as you add/remove errors over time. Does Roc guard against that happening? Should it? Can it?

Brian Carroll (Aug 12 2023 at 15:38):

That unreachable code would cause a compiler error in Roc, because of how tag unions work. They're "open" tag unions, unlike PureScript, Haskell, Elm, etc. I think there's a section in the tutorial about it.

Brian Carroll (Aug 12 2023 at 15:39):

I'm not sure what you mean by scoping though. Haven't heard that term in this context before.

drathier (Aug 13 2023 at 11:40):

I was talking about variant types in purescript, so open/closed structural sum types, not adt's. They should be the same thing as in roc

drathier (Aug 13 2023 at 11:41):

if error handling is only implemented in a library, it'll likely have this same issue as purescript does, which is why I was wondering. I want roc to not have this flaw

Richard Feldman (Aug 13 2023 at 16:15):

I'm not familiar with this in PureScript - can you give an example?

Richard Feldman (Aug 13 2023 at 22:03):

actually, I think I understand the question - is the scenario basically this?

• I chain some things together which produce an error type that's the union of all their error tags
• I write a helper function to handle these errors
• I put a type annotation on that helper function, which explicitly lists all the types it handles
• later, I change the original chained-together things such that some of the error tags no longer come up
• however, I don't change the type annotation on the helper function
• some of the branches in my helper function are now unreachable in practice, but the compiler doesn't tell me that because it's going off the (now overly broad) type annotation rather than the implementation.
• if I deleted the type annotation from the helper function, the compiler would tell me that some branches are unreachable

Richard Feldman (Aug 13 2023 at 22:03):

do I have that right?

Richard Feldman (Aug 13 2023 at 22:12):

if so, this is something Roc's compiler wouldn't catch today, but in the future I'd really like to have warnings for unused tags in type annotations (and unused record and tuple fields, similarly) but we don't currently have those

drathier (Aug 14 2023 at 19:38):

Yes, Richard. Except that the type is always inferred, not explicitly annotated. It's usually annotated using _ wildcard types in type annotations, precisely to avoid the problem you just described to a large extent. Sadly it doesn't help all the way, which is why I asked.

In purescript I'd be using https://pursuit.purescript.org/packages/purescript-veither/1.0.3/docs/Data.Veither#v:vhandle to handle one error tag at a time, so that you can handle some and let others "bubble up" one layer. However, if you do handle one error with vhandle, the compiler will now infer that this variant/row is in the row of error variants, and won't ever warn or compile error on it, even though the handler is unreachable code.

I'm hoping that you're not chomping off one of the variants at a time, and that you're casing on values instead? As long as nobody writes helper functions, that should work, but can we make it work with purescript-style helper functions too? Idk :)

Last updated: Jun 16 2026 at 16:19 UTC