context.addInitializer for class fields

[trusktr]

#469 was closed, but there was no explainable resolution.

No one there was able to explain exactly why a returned function is better than a function passed to context.addInitializer, and why only field decorators should return a function while other decorators use context.addInitializer.

A claim was made in that thread that adding an initializer with context.addInitializer leads to less performance than if we return an initializer, however no explanation as to why has been given.

On the other hand, the other issue does describe how context.addInitializer for fields would not lead to classes with slower initializers (because why would the mere act of returning a function vs passing a function affect how that function's performance later on?), and that the development experience would be more consistent with other decorators.

[trusktr]

If there's anything I learned from previous decorator implementations, it is that API inconsistency makes development difficult, requires a bunch of conditional checking, returning or not, etc. Consistency makes code easier to organize and understand.

[pzuraq]

This was answered in the other thread multiple times. As it stands, the proposal has moved to stage 3 and has been advancing steadily. There are no blockers on the committee over this issue, so API design consistency is not an issue.

I don’t want to restate the reasoning, you can see it here: #469 (comment)