"Ontological evasion" is a bad term. It makes it sound as if someone designing a 3GL wants to avoid an ontological primitive because of a strong disdain. Soldiers evade capture to avoid torture. Refusing to allow programmers access to a pointer construct is a security principle endorsed by parts of the US federal government. "Ontological evasion" might be more suited to denying climate change by refusing to admit PCR methods for calculating historical baselines of CO2.

I’m voting to close this question because the motivations for excluding pointers from a 3GL are not fundamentally metaphysical, but are alleged to be security best practices (avoiding buffer overruns, injection attacks, etc.)

@JD VTC is your prerogative of course. But it's about as sagacious as saying trolley problems should be closed because we don't discuss railway engineering out here or BigBang questions should be closed because we have a more dedicated astrophysics SE. As I pointed out the pointer ↔ memory issue is an example of the phenomenon. As for bad term — that's why I gave the alternative elision. As for the security direction — that only strengthens the relevance — think a philosophical (logical, rhetorical) sort of fallacy in a technical area causing some serious mishap

The trolley problem is an ethical dilemma. The inclusion of pointer arithmetic is simply a design problem in software engineering. Some languages have pointers, others do not for security reasons, and all compilers manipulate memory addresses as part of their semantic action. The dispute posted is a minor quibble over what constitutes a pointer. I'm not sure there's any real metaphysical issue at play here.

You seem to be using "metaphysical" as a synonym for "ontology". Metaphysics is somewhat vague and loose compared to ontology which is usually much more definite. eg en.wikipedia.org/wiki/Upper_ontology And en.wikipedia.org/wiki/Ontology_(information_science)

@JD Anyways Ive added an addendum [Also see above comment where I forgot to tag you]

I'm not certain I understand the question, but when you speak of ontological evasion you might be thinking of ontological reductionism, which is the view that we can account for language about objects at one level in terms of language about objects at a lower level, and when we do so then somehow we have explained away the existence of the higher level objects.

@Bumble And we can do that reductionism improperly with category errors eg Saying Everything is {Hydrogen, Helium... Plutonium, Californium} is ok; Saying Everything is {electrons, protons, neutrons} is ok — another level. But what if we say Everything is electrons protons and hydrogen? Please wait till I add a detailed reformulation to the question...

Pls see the newly appended reformulation @Bumble. And tnx to your question Ive a subsection on reductionism

Actually, I like the term "ontological evasion". Perhaps because I'm firmly in the camp of "if it walks like a pointer, quacks like a pointer, flies like a pointer, I'll call it a pointer!" camp. And because I think that this term actually describes quite precisely what C++ & co. are doing when they talk about "references": They actually mean to say "pointer", but the term got so burned in the flame wars that they give the beast different names, trying to tame it a bit in the process.

@cmaster-reinstatemonica [CS-ist hat on]: Well there are different levels of firstclassness. Full scale firstclass: pointer; semi-firstclass: reference (var parameter in Pascal); non firstclass, only in the meta-language (language manual): address. Well that's the C (C++) world and widely accepted or at least tolerated. [Philosopher hat on]: Programming lang details are somewhat remote. In effect only the semantics matters. So the pointer vs ref vs address etc distinctions seems less relevant

Btw, a good deal of the reasons why I would always call C++ references "pointers in disguise" can be found in the second part of my answer to a question about null references (stackoverflow.com/a/42520025/2445184). It's basically that the "reference" abstraction is so leaky that they are in no way easier to handle than C++ pointers.

I'm not really sure I understand exactly what you are getting at here, but I might be getting stuck on what seems to me to be an invalid premise. I've seen a lot of people write things like "why does Java have a NullPointerException when it doesn't have pointers?" The thing is that Java does have pointers. The JLS tells us that the value of a reference is a pointer. The fact that the language doesn't allow for direct interaction with pointers doesn't mean they aren't part of the language.

I'm learning Rust and I think maybe it might give a good example of what you mean. Rust has no class keyword. It has struct and Trait. You can put these together and get a lot (but not all) of the features of classes/OO. Is that the kind of thing you are talking about? I think in that case it is to highlight the differences in behavior. But you are looking for a term that describes this term substitution at a high level, right? 'Euphemism' comes to mind.

This is extremely unclear & rambling. "The question arises" You don't actually define "ontological evasion" or ask a clear question about it. It's not clear what your "context" is the context of or how your 2-statement quote "displays the dispute". What dispute? "the question is not" What is the question? Adding more & more to something unclear doesn't make it clear & anyway you don't connect your additions to what you wrote before. Please clarify via edits, not comments & delete & flag obsolete comments.

Sorry @philipxy. The paper for which I wanted the term has a nearer deadline than imagined. So the rewrite will have to wait (for now)

If you pull on the right string you get the right thing. I don't see more to it than that.

This doesn't seem a good example, it is confusing the abstraction and the interface. For example the implementation of a reference in Java may be a pointer (and it is in most JVMs) but not necessarily (for example it may involve two pointers to allow reorganization of the heap). There is a good reason for separating the abstraction from the implementation when discussing programming languages.

"elided pointers are called references" is simply incorrect. In C++ a reference is another identifier for an existing variable. Pointers may be used in the implementation of references, but they may not actually exist in the compiled program at all (try comparing the address of a reference with the address of the variable it points at) and the reference is simply a compile time convenience.

@cmaster-reinstatemonica sorry C++ pointers and references are not the same thing. For a start a reference is not actually a variable and doesn't have a storage allocated to it like a pointer does. You also can't have a null reference. Now if you were talking about Java you would have a slightly better case (as most JVMs implement references using pointers - but they don't have to).

The CS terms you use have vague generic meanings & specific meanings in certain contexts/languages. Moreover almost all you say about specific languages is wrong/misconceived. Please use as few technical terms as possible & define them & use simple language & minimal specific examples & say what you think is going on in each example. Similarly the philosophical terms you use are general & referencing does not help to explain what you haven't clearly written; one would have to know what you are talking about in the 1st place in order to argue that such terms could reasonably be applied & why.

@DikranMarsupial You are blinded by the abstractions according to the C++ standard. What you need to understand is the actual machine code that your compiler spits out. And when you do that, you find that there is actually zero difference between pointers and references, that both are stored within the same amount of bytes, that null references are dead simple to create, and that it's only the thin abstract language surface that waves its hand saying "references are not pointers". Please take a bit of time to thoroughly read the answer I linked in my last comment for details.

+1 for your answer on SE though, it is a good answer, but it doesn't mean references and pointers are the same thing. Create a local variable, create a reference to that local variable, and the reference does not exist anywhere in the generated code, you just have two identifiers (in the high level source code) for the same variable. The compiler hasn't optimised the pointer away - it was never there in the first place. The compiler uses pointers to implement references, on some occasions, but only where it is necessary.

In C (and to a slightly lesser extent) there are hacks that will get round a lot of restrictions, that is one of them, and it involves undefined behaviour, so YMMV on whether it "works". This is the downside of what makes C and C++ useful - just because you can do something, doesn't mean you should.

@DikranMarsupial The compiler is free to remove any local variable that's not actually needed. Whether that's a reference or a pointer is irrelevant. Reference semantics make it easier to avoid storing the pointer's value on the stack, though. However, any reference argument does have a place where it is passed, be it stack or register. And any reference within an object adds to the size of that object. That you cannot take the address of a reference does not mean that it doesn't have one (no memory storage without an address). It only means that C++ does not allow you to get your hands on it.

" The compiler is free to remove any local variable that's not actually needed." you are not reading what I wrote. The local "variable" (the reference) never existed to be removed. Identifiers and variables are not the same thing.

@DikranMarsupial Oh, I saw that. And I know the C++ standard parlance around it with references being "aliases" of the object itself, etc. And, of course, they do not need to be stored anywhere if the compiler knows where the object itself can be found. Nevertheless, the same goes for a declared pointer variable. And references do need to be stored when they are a) function arguments, b) non-static class members, or c) function return values. In all three cases, a register or memory chunk needs to be reserved to store a value that is the address of the referenced object.

@DikranMarsupial Whether an objects address needs to be stored (in memory) or not does not so much depend on whether it's declared a pointer or a reference (that distinction is only relevant for the semantics of the virtual machine), but rather on whether the compiler knows how to compute the address without the stored value. But we are getting seriously off-topic here, we'd better cut this discussion short.

@cmaster-reinstatemonica sorry, you are focussing on implementation only and not the meaning of the term. To understand programming languages fully you need to be aware of both the abstraction and the implementation. The compiler is free to implement references in any way that it sees fit to do so. Pointers explicitly store memory addresses.

@DikranMarsupial Assuming that the abstraction and implementation are separate and separable is very much what this question is about. Languages like Haskell hve no memory so they can claim to have no pointers -- IMHO correctly. All others (where the semantics depends on memory layout) are futzing around if they say you must understand memory but you need not know pointers

@Rushi, so abstraction was the term you are looking for?

@DikranMarsupial Improper failed leaky abstraction if you like -- but without the CS jargon. See my last section to Bumble in the question. How can one claim to have provided an abstraction if the details abstracted away turn out to be not abstracted away? See this question. IMHO you must willy nilly talk of something pointerish to explain it. As a language designer you may do -- as Java,Python,Ruby,JS do -- and say we have no pointers. As a teacher there is no such option (1/2)

... As a teacher you are compelled to explain the language in a convoluted ontology that the language fails to provide (2/2)

@Rushi I don't see anything improper or failed in e.g. the abstraction of a Java reference. In the case of C++ references, there isn't much of a failure there either as the programmer has to exploit underfined behaviour. If the language specification says "it is not defined what happens if you do this" then it isn't a failure of the abstraction if you do so. YOU DON'T NEED TO TALK ABOUT POINTERS TO EXPLAIN WHAT A REFERENCE IS IN C++. The reason we do so is that some are abstract thinkers and others prefer to also concrete implementation - consider your audience. I DO teach java/C/C++.

The point of an abstraction is to allow you to use something without having to think about how it is implemented. That doesn't mean you don't need to know how it is (likely) to be implemented, just that you don't need to think about it in order to write correct code. It makes programming simpler.