[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!!
Bruno