const methods prevent storing context in subclasses

[gitmodimo]

What is the reasoning behind using const methods everywhere? This prevents storing(modifying) global context within the derived classes. I understand that it is reasonable assumption for queries to not modify the context, but at least mutation should not have cont methods. It would also be useful to modify context also in subscriptions (and queries since they can be the same datatype?).
I see no drawbacks in dropping const in methods altogether. Am I missing something?

[wravery]

The original reason was what you suggest for queries/subscriptions. Because they should not have side effects in a GraphQL service, using const reinforces that. There are 2 ways to work around that for a data loader or caching mechanism:

1. Define a type which inherits from service::RequestState and mutate data stored there. This is more of a theoretical pattern; I haven't built any samples that use this for more than testing.
2. Use mutable on fields which store the cache state, or use const_cast within the methods that need to change something.

Most of the times I've used this, I've been binding a GraphQL service to another pre-existing API or data model (e.g. https://github.com/microsoft/gqlmapi, which is the most complete public example). The service projection acted as a facade for the real model, and the facade itself could be immutable except for any resources that it needed to track and manage. I've typically used mutable for those member variables.

I don't remember deciding that the Mutation type should be immutable as well, but differentiating it may just have been something I never implemented. I've also tried to avoid changing the signatures of the generated code between major versions, since that would be a breaking change for existing projects, so I can't change it till I'm ready for 4.0, which I've started planning. I'll add this to the list of potential features.