You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding ticket #3974, one favored practice to deal with dynamic calls involves:
a) know where they occur: -Ylog:cleanup -Ydebug
b) manually create a named class/interface, and use that as the explicit return type of the expression instead of a refinement type.
Should the refactoring in (b) above be part of the compiler, or is it for lint? In some cases a block-local class would be added, othertimes a template-level one (with the same visibility as the LHS of the assignment?). And, after adding a named type (before CleanUp) retyping is needed. Any cons other than that?
The text was updated successfully, but these errors were encountered:
@magarciaEPFL said:
The recipe above does away with reflective calls in several situations, but some remain. For them, a refinement type reference can sometimes be traced back to a single allocation site, thus guaranteenig that a named class can be inserted instead. Looks like deciding whether one such usage can be "traced back to a single allocation site" is a task for points-to analysis. For example, the following POPL 2011 accepted paper presents recent ideas on that:
Regarding ticket #3974, one favored practice to deal with dynamic calls involves:
a) know where they occur:
-Ylog:cleanup -Ydebug
b) manually create a named class/interface, and use that as the explicit return type of the expression instead of a refinement type.
Should the refactoring in (b) above be part of the compiler, or is it for lint? In some cases a block-local class would be added, othertimes a template-level one (with the same visibility as the LHS of the assignment?). And, after adding a named type (before
CleanUp
) retyping is needed. Any cons other than that?The text was updated successfully, but these errors were encountered: