Re: leakproof

* Andrew Dunstan wrote:

> Returning to the original point, I've come to the conclusion that
> "pure" isn't the right way to go. The trouble with "leakproof" is that
> it doesn't point to what it is that's not leaking, which is
> information rather than memory, as many might imagine (and I did)
> without further hints. I'm not sure any single English word would be
> as descriptive as I'd like.

Jumping into the bikeshedding here, I'm not convinced that all that
many users would immediately jump to the wrong conclusion (that being
"free of memory leaks"). Rather the opposite, indeed.

IMHO, you may be looking at this through "C developer colored
glasses", where any "leak" must immediately and without doubt be a
resource leak of some kind. As Don Baccus pointed out, it would be a
highly unusual function that was not at least intended to be free of
memory leaks.

A DBA, on the other hand, might -- and, again, this is MHO only -- not
decide what the attribute must mean without consulting the
documentation. If she was especially concerned about information
security/data protection, she might even guess right about what kind
of "leak" is meant. There is no chance of that with terms like SILENT
or PURE.

Of all the suggestions I have seen in this thread, I think LEAKPROOF
is actually the best fit for the purpose. My favorite alternative,
just to suggest one, would be NONDISCLOSING/NOT DISCLOSING, but I
prefer LEAKPROOF even over that, not just because it's shorter.

--
Christian Ullrich