Repository navigation
this-property assignments should use autoType to get control flow narrowing #37900
Description
Based on discussion in #37827, we could further improve typing of this-property assignments if we used autoType whenever we can't tell what type they should have.
This has three open questions:
- Performance.
- Is there benefit in real code? This only helps if (1) we aren't getting the right type some of time where (2) the auto type would get the right type. This is likely to be when a property is used repeatedly in a long method.
- What changes are actually needed. Just returning autoType doesn't work, because control flow narrowing doesn't seem to track this-property assignments as references.
Activity
sandersn commentedon Apr 10, 2020
implementation hiccup number 1 is that a union with
autoturns intoany, notauto.ahejlsberg commentedon Apr 11, 2020
I think you could do this by utilizing logic similar to that in
checkPropertyInitializationwhere we check that properties are definitely assigned in the constructor. In particular, the control flow walk we do inisPropertyInitializedInConstructorwhere we start from a virtual flow node representing all constructor return points. If you were to pass inautoTypefor the declared type andundefinedTypefor the initial type, the result should be a CFA'd aggregate of the possible assigned values upon return from the constructor. You'd furthermore have to special casethis.xxxproperty access expressions inside the constructor to similarly useautoTypeandundefinedTypefor declared and initial types (which would allowthis.x = this.x + ...without circularity errors). But for references outside the constructor you would rely on the CFA computed type.ahejlsberg commentedon Apr 12, 2020
Nathan Shively-Sanders (@sandersn) I've put up an experimental prototype of this in #37920.