Should `AnnoyIndex::save()` be a `const` method?

[LTLA]

Or: why does save() need to unload() and then load() the index again? Intuitively, I would have expected that a save() operation would not modify the object being saved.

To provide some more context: I maintain a wrapper library (https://github.com/knncolle) that provides a common interface for various neighbor-search algorithms. One recent extension of this interface was a save/load mechanism for pre-built search indices. When I was designing the part of the interface, I defined the saving method to be const, which is my way of indicating that it is safe to save the index while doing other const operations (e.g., searching on the index) in parallel.

This approach has worked pretty well for some other NN algorithms until I got around to implementing these methods for Annoy. The AnnoyIndex::save() method is not const, and I can't pretend it is, as that would mislead a user into, e.g., attempting a search at the exact same time that unload() runs inside save(). My current hacky workaround is to extract the _nodes array and save it manually, which works fine with AnnoyIndex::load(). However, it would be nice to just call AnnoyIndex::save() if it were const.

The long and short of it is that, if save() didn't do this unload() + load() dance at the end, it could be marked as const like many other methods in AnnoyIndexInterface. I'll admit that I don't understand why the unload() + load() is necessary - after all, the index was working just fine before I called save(), so why reload it? But if reloading really is unavoidable, perhaps it can be put into a separate method that calls save() (now const), then unload(), then load().