There would seem to be no reason why the getter methods generated in C++ for XPIDL attributes shouldn't be made 'const'.

I don't see why you would be able to ass-u-me that calling a getter wouldn't mutate the state of the object. I'm sure we can find existing examples of getters that do: nsLocalFileUnix, for one, updates internal state on the first property access. Why would you want to make these |const|? What does it win you? If |Release| isn't also |const| -- and that would be silly -- you can't do proper XPCOM ownership things on it in many cases, so it becomes tricky to get a |const| reference to an XPCOM interface pointer in the first place.

You of course can't--and thus don't--assume that the getter won't mutate the object. 'const' is used to enforce the notion of 'logical constness'--which means that any change to the object is irrelevant and opaque to the caller, rather than meaning that the object does not change at all. I am quite skeptical that getters should ever not be logically const. However, "What does it win you?" is a much better question, and after thinking about this a bit more I came to the same conclusion you draw here. Since it is effectively impossible to make the 'const promise' for an object, there's really no point to pretending it can be made at all. So I'm inclined to do a 180 and vote for WONTFIX or INVALID here.

Marking INVALID based on erudite discussion. Also see bugzilla bug 7646.

vrfy invalid