Prevent accidental proc overwriting, proc signature overloads

Commencez par lire les deux propositions et la discussion sur la sémantique de final, overwritable et overwrites. L’issue ne nomme aucun fichier, test ou point d’entrée, et son achèvement dépend de la décision concernant le comportement des mots-clés, de l’évaluation de la correspondance des signatures et de la réalisation d’une recherche utilisateur ou de la télémétrie avant l’implémentation.

A discussion came up about being able to overwrite procs. There are definitely good use cases for being able to overwrite procs, but the discussion was that perhaps this is not a good thing by default/generally.

A number of proposals were offered, summarized here. For clarity, the term "final" is taken to mean that a proc cannot be overwritten, whether or not there is a keyword final involved.

1. No change in existing behavior, but a new keyword final is introduced, and when applied to procs, prevents them from being overwritten elsewhere.

• Pros: No user code has to change. The implementation is simpler, and doesn't require a phase in period.
• Cons: If a user is accidentally overwriting a proc when they didn't mean to, this feature will not benefit them.

2. Add overwrites/overwritable/overwrite keyword(s). This changes existing behavior, so that all procs are final by default, but procs that are marked with some combination of either/both overwrites and/or overwritable are allowed to be overwritten.

• Pros: It's impossible for users to miss accidental overwrites, as this is much stricter.
• Cons: Behavior change, requires users to change code and requires a phase in period. It seems unlikely that this would be a widespread problem, but in general this would require a phase in period, and we should create telemetry on this to count how many people are affected, and the magnitude that they are affected before making this functionality visible to users at all.

For option 2, there is still a need to determine the specific keywords that are used. Do you put the overwritable keyword on the "master" proc, and the overwrites keyword on the sub-proc? Or do you just have a single keyword overwrite which you tag on all procs that are intended on being overwritten and the procs that overwrite them? This is a minor discussion that needs to happen still, but does not materially change the overall decision.

Another discussion is to also perform signature matching on non-final procs. So redefining a proc (which is either implicitly or explicitly overwritable) with a new signature should be disallowed. I generally support this, but this is a different decision and implementation. This may however prevent valid use case, so further user research needs to be done to provide input to this decision.