New Issue: Should there be a way to prevent methods from being forwarded?

Notifications Issues
1

18875, "e-kayrakli", "Should there be a way to prevent methods from being forwarded?", "2021-12-16T00:24:33Z"

Currently, a forwarding field declaration can also have an except list where the forwarder can choose what not to forward. Should the forwardee have a say in this?

This came up in my work with chpl__serialize and chpl__deserialize work. Which was already pointed out in Compiler-generated 'chpl__serialize' for type forwarding to a string lacks 'chpl__deserialize' · Issue #13265 · chapel-lang/chapel · GitHub in a more specific scope. Under that issue BHarsh stated that it doesn't make much sense to forward chpl__serialize and chpl__deserialize, and I agree with that. I think some of the following can be attractive:

  • Have methods say that "I don't want to receive a forwarded call". An annotation is the first thing that comes to mind, but we probably want something more concrete.
    • We can think of a keyword (eg, explicit, which is kind of similar to the meaning in C++, but only kind of). So an explicit proc must be called explicitly rather than being invoked as a result of a forwarded call.
  • We can have a list of methods in compiler that prevents forwarding. This is attractive only if there are other methods that we may want to include in this category.
  • If we were to have a list of method names that we are preserving (hash, writeThis etc), we can put special semantics for some of those methods. eg, "chpl__serialize (or @serialize) is not forwarded"