SIP 9 and SIP 10 transfer signature difference :-/

friedger · March 18, 2021, 2:38pm

There are two SIP that include a transfer function in SIP 9 and SIP 10. Unfortunately, the response type do not play nicely with regards to the errors, only uses uint the other {kind:(string-ascii 32), code: uint}.

feat: proposed fungible token trait by hstove

There is also a discussion about error code in clarity in general:

github.com/clarity-lang/reference

Error types support

opened 10:47PM - 26 Oct 20 UTC

agraebe

We discussed improvements for Stacks tooling lately and identified a pain point …inside Clarity related to error handling. It seems that error types are usually created as constants, with the name representing the error type. The constant would get an integer value and returned whenever an error occurs. Developers would need to take the value, open the contract, and read the constant name to understand the error type. @kantai suggested we could consider error enums to support better error handling. @kantai - I'm creating this issue as a starting point for the conversation and I'll let you chime in on the proposal and details

What is the process to bring SIP 9 and SIP 10 inline? Is it already too late as the sips are in activation process.

//cc @jude @hank

jude · March 18, 2021, 3:27pm

Neither SIP is ratified yet, so you’re more than welcome to make changes

friedger · March 18, 2021, 3:41pm

Isn’t ratification automatic after activation?

jude · March 18, 2021, 3:50pm

SIP-000 requires the steering committee to follow the SIP activation procedure to determine whether or not the SIP is ratified, but it doesn’t place a deadline on the SIP author to make changes to the SIP. If you updated the SIP’s Activation section to stipulate that the trait with the intended method signatures must activate, then that would be permitted.