sensen7
In the context of the wave of post-1492 European migration to America, I would define it to mean as anyone who isn't coming from that specific migration wave. It would remain easy, so long as the specific migration wave is still easy to distinguish from the the others.
You're now saying explicitly that if some new archeological evidence showed multiple waves of Polynesians in large numbers, then you would suddenly have trouble defining the distinction between a native American and an European in the post-1492 context, but this still seems completely absurd to me. So I'm afraid I don't really know what you're talking about.
The point that I was making is that this is the "definition" I would use for Britain as well, when discussing a very specific phenomenon of modern migration into Britain. Anyone who was there before the modern wave counts as native. As with all attempted formal definitions of real world phenomena, you can keep digging at and asking whether e.g. the Polish or Irish waves of immigration are distinct from the "current" ones that people are talking about. But there shouldn't be any doubts about the Normans 1000 years ago any more than there would be about the hypothetical Polynesians.
>Britsh history simply makes it impossible to come up with a sensible definition of indigenous
Taking the example of the Normans that you mentioned somewhere else in the thread, what's the difference between them and your hypothetical pre-Columbian group? Why does the Normans make it impossible to come up with a sensible definition of indigenous when another migration wave arrives, while the hypothetical pre-Columbians don't?
That's not really what the argument is about, it's about whether such a group would invalidate the concept of "native American" entirely such that it wouldn't be meaningful to distinguish between the native Americans or the non-native European Americans. That's effectively what you're arguing for Britain, and it's absurd.
The fact that the native population of Britain changed repeatedly thousands of years ago doesn't seem very relevant either. Are you saying that if new evidence showed that the native populations of America or Australia were the result of multiple ancient waves of migration rather than just one, that would change anyone's mind on which ones are truly the native Americans or Australians? That's obviously absurd.
If you really want to turn this apparently simple discussion about the common meaning of words into a matter of first-principles definitions, I guess I could give it a try, and it would probably have to bring in things like whether the waves of migration retained a significant identification with their place of origin. But it seems totally unnecessary.
What they're describing is the downstream effect of not designing APIs that way. If you could have a single giant GraphicsState and define everything as a method on it, you would have to pass around barely any arguments at all: everything would be reachable from the &mut self reference. And either with some annotations or with just a tiny bit of non-local analysis, the compiler would still be able to ensure non-aliasing usage.
"functions that each take 20 parameters and return 5 values" is what you're forced to write in alternative to that, to avoid partial borrowing errors: for example, instead of a self.resize_framebuffer() method, a free function resize_framebuffer(&mut self.framebuffer, &mut size, &mut several_other_pieces_of_self, &mut borrowed_one_by_one).
I agree that the severity of this issue is highly dependent on what you're building, but sometimes you really do have a big ball of mutable state and there's not much you can do about it.
NLL's final implementation (Polonius) hasn't landed yet, and many of the original cases that NLL were meant to allow still don't compile. This doesn't come up very often in practice, but it sure sounds like a hole in your argument.
What does come up in practice is partial borrowing errors. It's one of the most common complaints among Rust programmers, and it definitely qualifies as having to fight/refactor to get obviously correct code to compile.
If you don't care about the map part, you can get the same behavior by just moving the last element in the place of the newly removed element. This invalidates all indices, which is what the DenseMap's overhead is meant to avoid, but Vec's remove also invalidates indices. Vec's remove is strictly worse except that it preserves the ordering if the Vec is sorted.