Stabilize pallet view functions

[jsdw]

Currently,. pallet view functions are behind a #[pallet::view_functions_experimental] attribute. We should come up with a plan to stabilize them.

Stabilizing pallet view functions unblocks stabilization of V16 metadata, which exposes the necessary details for clients to interact with view functions.

A couple of things on my mind to confirm:

1. Are we happy with the naming (we have "pallet view functions" and "runtime apis"?
   • I still wonder if we should just call them "pallet apis" and "runtime apis" for consistency? But I know there has been talk of Runtime View Functions which I assume would replace Runtime APIs?
2. Pallet View Functions are called by hashing $palletName + $methodName ( $argTypeNames ) -> $returnTypeName or something like that, while runtime APIs are called by providing $palletName + _ + $methosName. - AFAIU we do this more complicated approach to enforce immutability of view functions, but this mostly just chanegs the failure mode from "method args invalid" to "method not found" when quering for a method that has changed. Is it worth simplifying the calling approach to be more similar to runtime APIs?
   • Simplifying the approach would also mean we don't want to embed a 32 byte query ID with each view function in the metadata (which we do because constructing it requires all of this hashing etc so easier to just provide it rather than have users construct it).
3. Anything we need to think about / change to support subscribable view functions in the future?
   • I don't think so offhand; the interface stays the same but we track storage accesses under the hood to know when to send updates.

If others think that the answer to each of those is "I'm happy as is" then from my PoV I'm all good to see the mstabilized.

What do others thing? Anything else we need to think about before stabilizing?

\cc @kianenigma @re-gius

[re-gius]

1. I think pallet view functions would be a better selling point for this functionality, also making it more clear for Solidity devs coming into Polkadot. I'm also in favor of moving to Runtime View Functions, but I can see why that's confusing for Polkadot users that are used to Runtime APIs.
2. Wouldn't the current setting make subscriptions easier? If we only used the method name, adding a new method with the same name and different args could mess with subscriptions (?).
3. Cool, that would be nice in terms of developer experience.

[jsdw]

Wouldn't the current setting make subscriptions easier? If we only used the method name, adding a new method with the same name and different args could mess with subscriptions (?).

At least in terms of how pallets are written, it's impossible to have two methods with the same name though? But in any case I would want to prevent users from being able to do this; it would be a recipe for confusion if people could write view functions with different names imo.

I don't know enough about how subscriptions would be implemented to know how any particular means of querying a view function (whether using this hash appraoch or name or whatever) would make a difference to them; could you elaborate on that bit perhaps?

I think the hash-of-name-and-types approach comes from some ethereum proposal; is that right? I'm struggling to understand the benefits of it as opposed to some simpler scheme so would love to have a clearer picture of this!

[re-gius]

Yeah, probably having two view functions with the same name would be confusing not only for subscriptions, but it would be a bad practice in general.

The hashing-based dispatching mechanism for the method signature part is very similar to the one used for ERC721 selectors, so is more familiar to Solidity/EVM, like the naming view function is. It's also less likely to cause errors/confusion if a parachain decides to implement its own pallet view functions, because hashing (differently from enums) makes it unlikely that these view functions will have the same encoding as the ones in Polkadot/Kusama.

In the end, I would say the current setting is more clear for new users coming to Polkadot, especially smart contract developers that already know how view functions work and how their dispatching mechanism is implemented in Ethereum. However, I can see that this is not coherent with the legacy dispatching mechanism for Runtime APIs.

[jsdw]

However, I can see that this is not coherent with the legacy dispatching mechanism for Runtime APIs.

Perhaps there's a path whereby we expose existing Runtime APIs as "Runtime View Functions" (in addition to how they are currently exposed), so that you can use either mechanism to query them, and then eventually we can transition the way that you declare them to be more consistent with Pallet View Functions and deprecate/remove the "old" Runtime API declaration/call stuff.

I've no other strong opinions besides wanting consistency (and avoiding having two different mechanisms around for a while which will just confuse people), so am happy with Pallet View Functions as they stand today if that's the direction we want to take :)

[jsdw]

Closed by #7960