> Or use references instead, which are conceptually the same thing.

In the same sense that a donut is topologically the same as a coffee mug, sure.

> You quite clearly stated their purpose was very niche.

I did not. I said they weren't needed outside of specific domains, which is not the same as "niche".

> we were discussing the needs of learning the concept of pointers

Per my original comment, no, we were not. I wrote of needing pointers. I said nothing about the needs of learning the concept of pointers.

My comment was, and I stand by this, that pointers are a fantastic example of accidental complexity. They are present in many programming languages, and are a thing people have to use as a consequence but which are not themselves necessary for the problems that many people intend or need to solve. References, which are not the same as pointers except again in the sense of donut = coffee mug, are a more general concept that has broader utility than pointers without the added complexity that pointers bring to the table (though depending on the manner of the references they may bring in their own, see both Python and Java and the unintentionally altered collection values).

The complexity is historic, not accidental. If you start with a linearly organised address space then you need some way to reference the items in it.

The physical address in the linear space [1] isn't just the obvious option, it's the only option. [2] It's a short step from there to indirect addressing via a linear lookup table, and/or simple address arithmetic to find items stored sequentially.

You can only avoid this by adding layers of abstraction which hide these mechanisms.

But you can only do that after the mechanisms are in place. Otherwise your "reference" is just an unimplementable idea with no meaning.

[1] Ignoring hardware paging, because that's usually invisible.

[2] Ignoring hypothetical magic associative O(1) key-value store hardware with the same speed as semiconductor RAM - which could be built at ludicrous expense, but would cause complexity issues of its own.

To be clear I'm using "accidental complexity" in the sense of Brooks. He breaks complexity in software systems, in his No Silver Bullet paper, into two categories: accidental and essential. My contention is that for most programers and programs pointers fall under the category of accidental complexity. That does not diminish their utility, nor mean that they never fall under the category of essential complexity (indeed, having spent most of my career on embedded systems, there are things we could not have done or done as easily without pointers). Just that, for most of the things people want to accomplish when programming a computer, pointers (though often not the broader sense of references) are accidental (i.e. unnecessary) complexity.

Lets not get stuck on defining what niche means. Its meaning has been defined for a while already. Niche = specific domain related. Anyway.

In which ways are references of broader utility? And what is so complex about pointers? The fact that it doesn't hide behind language magic? Well, that you can just ignore: I don't _need_ to see or edit the address it holds.

Funnily enough, I really struggled going to Java and python coming from C++ originally. What do you mean I don't know if I'm getting a copy? The semantics of passing something to a function were so confusing and I was never sure if I got a copy or not. Pointers made so much sense.