Prefer fill_n over fill where applicable

[AreaZR]

We can avoid doing the addition ourselves when we do this.

[StephanTLavavej]

This is a good cleanup, thanks for finding it.

Separately, I will comment: Please avoid force-pushing branches after creating PRs, as GitHub doesn't make it easy to see what's changed. (In this case, nobody had started reviewing so it wasn't an issue, but the general principle still holds.)

Rewriting history before you create a PR is fine (either to squash all changes into a single commit, or to structure complicated changes as a series of comprehensible commits). After creating a PR, you should push ordinary commits to fix things like typos, which is what I see happened here.

We've asked you to avoid force pushes in the past, and you've acknowledged this, so I am confused as to why it keeps happening. If you have a tool that eagerly force-pushes, I recommend exploring how to configure it.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

fill_n(back_inserter(comments), 100, "Thanks! 😻🎉🚀");