I've been reading several comments on the list and I think a few different things are being discussed concurrently so I'm hoping to clarify and address them. There are two interfaces: one for implementers, and one for users. A goal for implementers is to not have to require any Hash2 headers for their algorithms to be used by the library. For users, we want safe interfaces that always do the Right Thing. hash_append is a proven interface for working with user-facing structures and solves the subtle and difficult problems it needs to, such as the "ab" | "c and "a" | "bc" case, as we've already discussed. Unfortunately, hash_append isn't really suitable as a safe interface for incremental hashing of byte streams, as we've noted that hash_append will append a hash of the size once it's done. update() works properly for hashing byte streams (as it must) but because it's intended as part of an implementation, it's not exactly suitable for most end-users who just want to hash their 3 GB file. We could even go so far as to say that it is an "unsafe" interface. So, we want safety. Vinnie has already alluded to using a free function hash_update which will accept a span. This is, as far as I can see, the best solution to the problems at hand. With this, we can achieve our goals for both implementers and users because the update interface doesn't have to change and then we can layer all the type safety externally to the free functions in a non-intrusive way. - Christian