Oh, underscore was a poor choice, wasn't it? I'll reuse $$ then; that shouldn't be able to collide with anything. (identCharToText never produces consecutive dollar signs, and no reserved word or built-in would start with a digit.)

Oh, underscore was a poor choice, wasn't it? I'll reuse $$ then; that shouldn't be able to collide with anything. (identCharToText never produces consecutive dollar signs, and no reserved word or built-in would start with a digit.)

Yeah, I think that should work.

On another note, should there be a golden test for this in the optimize tests? To ensure that the outputted JS doesn't have a name clash with a similarly named _two top-level member?

I think all an optimize test would do is ensure that the generated identifier looks the same, not that it doesn't collide with something else. We could write such a test but it doesn't seem to me like it would be worth it; I have a hard time imagining how the $$ prefix changes unintentionally, and if someone changes it intentionally then all that the failing optimize test will communicate is that they did what they intended to do.

What I'd much rather have would be something like a QuickCheck property that asserts that identToJs is injective (over the domain of inputs for which it doesn't error). We don't seem to have much of that sort of unit testing for simple and small units of code that don't change often, but I'd write it if you also think it'd be a good idea.

I think all an optimize test would do is ensure that the generated identifier looks the same, not that it doesn't collide with something else. We could write such a test but it doesn't seem to me like it would be worth it; I have a hard time imagining how the $$ prefix changes unintentionally, and if someone changes it intentionally then all that the failing optimize test will communicate is that they did what they intended to do.

What I'd much rather have would be something like a QuickCheck property that asserts that identToJs is injective (over the domain of inputs for which it doesn't error). We don't seem to have much of that sort of unit testing for simple and small units of code that don't change often, but I'd write it if you also think it'd be a good idea.

Gotcha. Then, I don't think it's needed for this small fix.