Do not let interpret doT numbers as integer, but as string about dot HOT 9 CLOSED

No, I assure you that that is not what users really want. You know what types your properties contain; doT doesn't. What if I had two numbers and I wanted to add them? Why would that be a less important use case?

from dot.

@Pointy because that's definitely not what you expect from something which clearly should output. {{=var}} should just output what's in var. It's documented as an output operation, then it should just output too, not do any additions.

from dot.

@bwoebi I apologize for not expressing myself more clearly; also, I think I better understand what you're asking for now. However, I'm a little confused. If it.number is a number, and it.string is a string, then

out = (it.number)+(it.string);

will result in a string concatenation operation, and NaN cannot be generated by that. (Maybe I still don't understand what the failure scenario is.)

from dot.

@Pointy Hmm, I think I've done something wrong in the original bug report. The failure is definitely present when both operands are numeric. Then they definitely add up, which my quick fix above fixes.

from dot.

Right, OK now that I understand, and I agree that I'd be pretty surprised by that (though I confess it's never happened to me, and I've got a lot of templates). I wonder if a simpler change that involved simply making sure that the out variable is initialized to an empty string would fix it?

from dot.

@Pointy Not really. The operands on the right are evaluated first before it's concatenated to the left...

from dot.

@bwoebi yes I've been playing with it and I see what you mean; any time that numbers are involved things can get weird.

from dot.

Oh yes, I see this can happen if numbers are somewhere in the middle of the template.
I made changes in the dev branch for this, please take a look and try it out.
I'll merge the changes into master after a couple of days if all looks good.

from dot.

Addressed in version 1.0.3, closing

from dot.