On Thursday, March 23, 2023 7:22 PM, Felipe Contreras wrote:

On Sat, Feb 18, 2023 at 5:12 AM Phillip Wood [off-list ref] wrote:

quoted

On 18/02/2023 01:59, demerphq wrote:

quoted

On Sat, 18 Feb 2023 at 00:24, Junio C Hamano [off-list ref] wrote:

quoted

Emily Shaffer [off-list ref] writes:

quoted

Basically, if this effort turns out not to be fruitful as a whole,
I'd like for us to still have left a positive impact on the codebase.
...
So what's next? Naturally, I'm looking forward to a spirited
discussion about this topic - I'd like to know which concerns
haven't been addressed and figure out whether we can find a way
around them, and generally build awareness of this effort with the community.

On of the gravest concerns is that the devil is in the details.

For example, "die() is inconvenient to callers, let's propagate
errors up the callchain" is an easy thing to say, but it would take
much more than "let's propagate errors up" to libify something like
check_connected() to do the same thing without spawning a separate
process that is expected to exit with failure.

What does "propagate errors up the callchain" mean?  One
interpretation I can think of seems quite horrible, but another
seems quite doable and reasonable and likely not even very invasive
of the existing code:

You can use setjmp/longjmp to implement a form of "try", so that
errors dont have to be *explicitly* returned *in* the call chain.
And you could probably do so without changing very much of the
existing code at all, and maintain a high level of conceptual
alignment with the current code strategy.

Using setjmp/longjmp is an interesting suggestion, I think lua does
something similar to what you describe for perl. However I think both
of those use a allocator with garbage collection. I worry that using
longjmp in git would be more invasive (or result in more memory leaks)
as we'd need to to guard each allocation with some code to clean it up
and then propagate the error. That means we're back to manually
propagating errors up the call chain in many cases.

We could just use talloc [1].

talloc is not portable. This would break various platforms.

--Randall