The NUOPC API does not currently leverage the type(ESMF_KeywordEnforcer). This makes it harder to extend the NUOPC API without risking incompatibility with user code that depends on positional argument matching (vs enforcing the argument keyword syntax).
While adding type(ESMF_KeywordEnforcer) should technically be straight forward, it would need to be announced as backward-incompatible, because it potentially requires functioning user code to be modified (adding of argument keywords).
The other aspect to consider is that the NUOPC API has not officially been included in the backward-compatible guarantee of v5.2.0r. However, at this point I think it is only a historical artifact of which parts of the ESMF/NUOPC API are tagged, and practically the expectation extends much further than the officially marked API. Still, it might be a good idea to review the NUOPC API when adding type(ESMF_KeywordEnforcer). This way, if there are changes needed in user code, this would happen in a single (major) release.
The NUOPC API does not currently leverage the
type(ESMF_KeywordEnforcer). This makes it harder to extend the NUOPC API without risking incompatibility with user code that depends on positional argument matching (vs enforcing the argument keyword syntax).While adding
type(ESMF_KeywordEnforcer)should technically be straight forward, it would need to be announced as backward-incompatible, because it potentially requires functioning user code to be modified (adding of argument keywords).The other aspect to consider is that the NUOPC API has not officially been included in the backward-compatible guarantee of
v5.2.0r. However, at this point I think it is only a historical artifact of which parts of the ESMF/NUOPC API are tagged, and practically the expectation extends much further than the officially marked API. Still, it might be a good idea to review the NUOPC API when addingtype(ESMF_KeywordEnforcer). This way, if there are changes needed in user code, this would happen in a single (major) release.