[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-opaque hamt type?

From: Bruno Haible
Subject: Re: Non-opaque hamt type?
Date: Sat, 03 Apr 2021 12:26:24 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; )

Hi Marc,

> Secondly, after having given it some more thought, the alternative protocol
> (which we have called more robust) seems to be harder to understand because
> "p != e" could then mean two different things. So I will leave the original
> protocol in place, which is easy to comprehend: If "old_hamt == new_hamt",
> no insertion has taken place and one has manually free the element one has
> attempted to insert. If "old_hamt != new_hamt" the element has been
> inserted and has now to eventually free "new_hamt" besides "old_hamt".

Yes, an API with 3 possible outcomes is easier to use incorrectly than an
API with 2 possible outcomes.

> After I have rebased my code to HEAD, I will commit the new module to
> Gnulib.

Yes please. Thank you for your great contribution!!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]