Support inferred error sets in recursion #2971
Labels
accepted
This proposal is planned.
contributor friendly
This issue is limited in scope and/or knowledge of Zig internals.
proposal
This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone
This is a proposal based on the question raised in #763. (If #763 is considered the tracking issue or the final word, please feel free to close this one -- I didn't interpret any of the comments there as conclusive.)
Thanks @rjtobin for resurfacing the issue in IRC.
Summary
If a call graph is recursive, a return type with inferred error set may trigger this compile error:
If all functions in that cycle use inferred error sets, the error is guaranteed to happen.
If at least one of the functions in the cycle has an inferred error set, the error may happen. Given this error set:
Changing
f1
to returnE!void
prevents the error. Leavingf1
alone and instead changingf2
to returnE!void
does not prevent the error. The outcome may be deterministic or it may be based on the color of the giant spaghetti monster's mood ring, I dunno.Proposal
Guarantee that inferred error sets are allowed even in cyclic call graphs.
Alternatives
Explicitly state that recursion is incompatible with inferred error sets. "Wait!" I hear you cry, "the documentation already says exactly that". It sure does, but it is also acknowledges that this limitation may be removed in the future. We just need to decide (eventually) whether to add support or officially make it unsupported for the language specification (#75).
Note: Currently, I am neutral on this enhancement. It's not blocking me. This issue is just meant to track it and aggregate potential use cases.
The text was updated successfully, but these errors were encountered: