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
The primary idea is to avoid having code paths where the compiler needs to handle either int or double. cc @mraleph@a-siva@aam who might be able to confirm whether it's indeed more efficient to have code that unambiguously uses always int or always double or whether actually using num isn't such a big deal.
(The secondary reason here is to keep the code clear and catch likely bugs. It's often the case that if your code involves mixing int and double, you've probably stumbled into a less-than-fully-designed case that needs more thought.)
Activity
a14n commentedon Sep 21, 2018
@Hixie what would you put in lint's description of this lint to explain why
num
should be ban ?Hixie commentedon Sep 21, 2018
The primary idea is to avoid having code paths where the compiler needs to handle either int or double. cc @mraleph @a-siva @aam who might be able to confirm whether it's indeed more efficient to have code that unambiguously uses always int or always double or whether actually using
num
isn't such a big deal.(The secondary reason here is to keep the code clear and catch likely bugs. It's often the case that if your code involves mixing int and double, you've probably stumbled into a less-than-fully-designed case that needs more thought.)
mraleph commentedon Sep 21, 2018
For computational kernels it is indeed better to have code that uses either
int
ordouble
notnum
.TFA sometimes might be able to infer what is stored in a particular
num
typed location - but not always.