For me it looks good, let's wait on another reason before merging

Hello, Thanks for you contribution ! 🙌

However, I have few question/suggestion that I'm free to discuss to make this snippet better.

Instead of returning a std::vector<int> why don't you return std::vector<bool>.
It make it more efficient to find if a certain value is prime or not (O(1) for vec<bool> and O(log n) for vec<int>, using binary search.).

An int take up to 8 bytes in memory as a bool take only one. For primes up to n we can wrote this formula:

• vec<bool> = ~n
• vec<int> = ~(n/ln(n)) * sizeof(int)

For n = 100_000, vec<bool> uses 12500 bytes as vec<int> uses 38000 bytes. (used int=4bytes)

Consider adding const to your parameter and noexcept to your function.
Also, if you are still planning to use a vec<int>, consider reserving the memory using the prime number theorem to make less allocation.

• primes.reserve(n/std::log(n));
• or, for a more precise allocation:

  double ln_n = std::log(n);
  double estimate = (n / ln_n) * (1 + 1/ln_n + 1.8/(ln_n*ln_n));
  primes.reserve(estimate*1.005);
  

• Or, a for a bit precision allocation:

  size_t count = 0;
  for (int i = 2; i <= n; ++i) {
   if (is_prime[i]) count++;
  } 
  std::vector<int> primes;
  primes.reserve(count);
  

Letting the vector grow itself seems a bad idea, when benchmarking, for n = 1000000 I got:

For n = 1000000:
there should be 78695.8 primes
Number of primes: 78498
Vector<int> size in bytes: 313992
Vector<int> capacity in bytes: 524288
Unused capacity in bytes: 210296

Even for smaller n, I always got 30-70% byte loss and for bigger n, the problem is worse