Which components will need NEPs to merge with near-sdk-rs?

[encody]

This is essentially the question: Which derive macros expose external methods that are not yet standardized via an NEP?

Component	Exposes Interface?	NEP Standard
standard::*	✅	✅
Event	✅	✅
Migrate	✅	❌
Owner	✅	❌
Pause	✅	❌
Rbac	❌	❌
Slot	❌	❌
utils::*	❌	❌
Approval / SimpleMultisig	❌	❌

In order to be merged into SDK, a component's Exposes Interface? column should match its NEP Standard column.

[ryancwalsh]

@encody If you have a moment, I'm curious about a couple things:

This is essentially the question: Which derive macros expose external methods that are not yet standardized via an NEP?

Are you saying that the question "Which code will require an NEP to be approved?" is equivalent to "Which derive macros expose external methods that are not yet standardized via an NEP?"

I feel like I haven't found a clearly documented answer to "Which code will require an NEP to be approved?" and didn't feel like Max's answer was super clear either, so I'm just curious what is leading you to your interpretation.

In order to be merged into SDK, a component's Exposes Interface? column should match its NEP Standard column.

I don't understand the wording of this.

Currently I see that Migrate, Owner, and Pause all have Xs for NEP Standard. So I initially thought you were saying that they'd need NEPs. But then because of that wording of the last sentence, it sounds like you're considering making changes to NCT to switch the ✅s of those 3 rows of the "Exposes Interface" column back to Xs.

[encody]

@ryancwalsh :

@encody If you have a moment, I'm curious about a couple things:

This is essentially the question: Which derive macros expose external methods that are not yet standardized via an NEP?

Are you saying that the question "Which code will require an NEP to be approved?" is equivalent to "Which derive macros expose external methods that are not yet standardized via an NEP?"

That is my reductive interpretation, yes.

In order to be merged into SDK, a component's Exposes Interface? column should match its NEP Standard column.

I don't understand the wording of this.

Currently I see that Migrate, Owner, and Pause all have Xs for NEP Standard. So I initially thought you were saying that they'd need NEPs. But then because of that wording of the last sentence, it sounds like you're considering making changes to NCT to switch the ✅s of those 3 rows of the "Exposes Interface" column back to Xs.

I'm saying so long as the first column is equal to the second column, we're good. It doesn't matter which column changes, just so long as they're equal. If that means removing previously exposed interfaces, fine, if that means proposing & standardizing an NEP, fine.

[encody]

To be honest, I think that all of the derive macros are generally good/correct in their current implementations, so I'd say we should take a look at NEP-standardizing all three of the deviant components: Migrate, Owner, Pause.

[ryancwalsh]

@encody Thanks!