I believe the vast majority of implementations would not override _preValidateTransfer's implementation in CreatorTokenBase to use the tokenId parameter, since per-token royalty enforcement configuration is rare, and tokenIds are not a dimension that's considered in the language used by the default validator's security levels.
Given that assumption, it looks like there's an opportunity to optimize the default examples to only call _validateBeforeTransfer once in the _beforeTokenTransfers / _beforeTokenTransfer hooks, instead of once per token, since the only parameter being changed in those loops is the unlikely-to-be-used tokenId. This can result in decent gas savings for any bulk transfer with a non-zero security level due to the external contract calls avoided.
Because this is a library, to ensure devs don't shoot themselves in the foot, the default examples could then also override _preValidateTransfer trivially and mark that function as non-virtual, to enforce the "tokenId won't be used" assumption.
I believe the vast majority of implementations would not override
_preValidateTransfer's implementation inCreatorTokenBaseto use thetokenIdparameter, since per-token royalty enforcement configuration is rare, and tokenIds are not a dimension that's considered in the language used by the default validator's security levels.Given that assumption, it looks like there's an opportunity to optimize the default examples to only call
_validateBeforeTransferonce in the_beforeTokenTransfers/_beforeTokenTransferhooks, instead of once per token, since the only parameter being changed in those loops is the unlikely-to-be-usedtokenId. This can result in decent gas savings for any bulk transfer with a non-zero security level due to the external contract calls avoided.Because this is a library, to ensure devs don't shoot themselves in the foot, the default examples could then also override
_preValidateTransfertrivially and mark that function as non-virtual, to enforce the "tokenIdwon't be used" assumption.