On Apr 13, 2020, at 16:31, hanw...@gmail.com wrote: > >> Does const serve a purpose here? The iterator doesn't carry through > with any >> kind of enforcement. The same question applies to try_retrieve() and >> to_alist(). > > It allows one to iterate over properties in a const method. > > What kind of enforcement are you looking for?
There's a tension between C++ and Scheme structures that I struggle with. In C++, a const method usually doesn't change the externally observable state of its object, and *usually* avoids returning a non-const reference to a component part, so as not to open a way for the caller to mutate the object. If this const method is not enforcing these things because SCM data structures have no constness, then what is the value in declaring it const? You've said that you're declaring it const so that it can be called from a const method. Granting that the caller may be const for a good reason, the suggestion that a Mutable_properties object will not be changed by a caller that calls properties.to_alist() is misleading. I think it would be better to declare methods as const where it agrees with reality, e.g. contains(). That way you can meaningfully pass a const Whatever& around and trust that the recipient can not change its state. I would do this even if the consequence is that passing a const Whatever& is not useful at present. In the case that concerns you--iterating the SCM list in a const method of a class that owns a Mutable_properties object—I think I would declare the Mutable_properties object as mutable. That way, all the owner's methods can do as they please with the owned Mutable_properties, consistent with its nature as primarily a SCM structure. In short, that way "const" means const, and "mutable" means mutable. — Dan