Rework anti-pattern doc about unsafe atom creation

[sabiwara]

Following the introduction of to_exising_atom/2 variations in #15483 and #15493.

[lukaszsamson]

Should we mention here other ways that can lead to dynamic atom creation like interpolation :#{foo}, ["#{foo}": 123], Code.string_to_quoted and other APIs?

[sabiwara]

Good call, also ~w[foo bar]a. Not sure what the plan is, given they're all unsafe it would make sure to deprecate them too and have people call String.to_unsafe_atom("foo#{1}") etc explicitly?

Code probably has more implications anyway (esp. eval_, can create/redefine modules and be much worse than atom leaks), so perhaps wouldn't include it here.

[lukaszsamson]

Code.compile*, assumes full trust as all other compiler APIs. AST/algebra operations like parsing or formatting are tricky because it is not obvious they may be unsafe

[josevalim]

I pushed some changes cause I think we can be more direct as we don't need to talk about to_existing_atom's pitfalls.

[sabiwara]

AST/algebra operations like parsing or formatting are tricky because it is not obvious they may be unsafe

I think that's fair, it's probably one of the common vectors where it can happen.

I pushed some changes cause I think we can be more direct as we don't need to talk about to_existing_atom's pitfalls.

Looks much better indeed, thanks!

[sabiwara]

@lukaszsamson What about something like:

Suggested change

	Finally, keep in mind that dynamic atoms could happen indirectly even if you are not calling `String.to_unsafe_atom/1` yourself. A typical example would be code parsing, using `Code.string_to_quoted/2` without the `:existing_atoms_only` or `:static_atoms_encoder` option.

@josevalim Also, this made me realize, would it be an interesting idea to support a list of atoms in existing_atoms_only? Assuming you're writing a sth like a calculator: [:cos, :sin, :exp, ...].

[josevalim]

@sabiwara I don't think we need to talk about that here. But we can add disclaimers to string_to_quoted if necessary.

Also, this made me realize, would it be an interesting idea to support a list of atoms in existing_atoms_only? Assuming you're writing a sth like a calculator: [:cos, :sin, :exp, ...].

In this case, I think simply defining the atoms upfront (as suggested here) is enough, because you need to validate what was parsed anyway. The big benefit of to_existing_atom/2 is to parse and validate at once.