Orelse return null

[pierrelgol]

please don’t touch my orelse return foobar it’s my favorite pattern in the language it reads so well, everytime I use optionnal in other language I miss it, especially in python or C++

[vulpesx]

That did occur to me, unfortunately it ran away, and I couldn’t put together an example in my head that I couldn’t get around. But that was just missing an extra layer of indirection.

@Sze

So if this unused error is for the sake of implementing the same API, then it is still needed so that implementations can be switched. This also means the compiler couldn’t easily say where it is ok and where not, so maybe it shouldn’t be a compilier error and instead some kind of project specific validation step that can distinguish between API vs non-API cases.

This makes more sense than my attempts to add an escape hatch to the compile error.

[npc1054657282]

@vulpesx

why would you use a custom tagged union instead of an error union?

After some thinking, I did come up with a reason sufficient to convince me that I should use error union instead of tagged union.

Overall, I used to think that error union and tagged union were basically equivalent from the perspective of control flow, and it would be clearer if tagged union could be used to distinguish those expected processing scenarios. But now I notice that there is a very significant difference between them in terms of control flow: errdefer

errdefer is used in a function that outputs an in-place allocated heap object. If the output is pre-allocated, it will only be cleared in cases where an error is returned. In this case, if there is a scenario where we do not expect to output the assigned object but do not return this scenario as an error but as a tag, then this assigned object cannot be correctly cleared by errdefer.

Although most of the time we do not return an assigned object, we can imagine what would happen if we passed the return value in the form of heap allocation. From the perspective that errdefer is executed correctly, many scenarios must be returned as errors. For those functions that do not use errdefer, for the sake of style consistency, it is indeed necessary to consider returning these tags as errors.

How to effectively isolate those “error” scenarios that must be handled from other unexpected errors in I/O, allocators, and downstream apis to reflect their critical status still requires me to continue exploring.

[Etienne_Parmentier]

This is definitely a feature Z.L.S could provide ! We could ask for ‘unused‘ errors, it should not be a warning though because of API matching as you said.