terminology: allocated object → allocation

[RalfJung]

Rust does not have "objects" in memory so "allocated object" is a somewhat odd name. I am not sure where the term comes from. "object" has been used to refer to allocations already in 1.0 docs; this was apparently later changed to "allocated object".

"Allocation" is already the terminology used in Miri and in the UCG. We should properly move to that terminology, and avoid any confusion about whether Rust has an object memory model. (It does not. Memory contains untyped bytes.)

Cc @rust-lang/opsem @rust-lang/lang

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[RalfJung]

This will break existing links to #allocated-object. Dos anyone have an idea how we could avoid that?

[ChrisDenton]

Inline html? Something like:

<a id="allocated-object"></a>

[traviscross]

This will break existing links to #allocated-object. Does anyone have an idea how we could avoid that?

Here's what we do in the Reference.

[RalfJung]

Yeah... but not sure if I can just put that in a doc comment.

[traviscross]

Agreed.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

I could have sworn it came from C++, but looking again I can't see any evidence of that.

So I guess it's from https://llvm.org/docs/LangRef.html#allocated-objects:

An allocated object, memory object, or simply object, is a region of a memory space that is reserved by a memory allocation such as alloca, heap allocation calls, and global variable definitions.

[saethlin]

Yeah, it came from the LangRef but also according to @nikic "allocated object" isn't even the LLVM internal terminology.

[RalfJung]

Does it come from LLVM? Before llvm/llvm-project@47822c80c1b25 they barely used this term -- it had no definition, was just mentioned in a few places.

[CAD97]

The terminology I think was intended to just use "object" as "thing." Given "allocation" is a functional name for the "thing" being named, and the extra semantics that the term "object" can imply, this is clearly a positive change in my eyes. Especially since there's no clear provenance (pun not intended) on where the "object" name came from.

I at least think I adopted the term "allocated object" to distinguish from the act of allocation — "the allocation" could theoretically refer to either the allocated memory block or the operation that creates it — but I think it's always sufficiently clear from context which is being referred to, and the concept of the "allocated object" is now familiar enough that the risk of "object" misleading readers is greater than that of not recognizing the allocation as a thing that the Abstract Machine cares about.

---

The one caveat to place on this is that of slicing "allocated objects" — this is easier to discuss if the AM concept has a different name than just the allocation. IIRC the consensus now is that our inbounds pointer arithmetic at least allows movement within the whole allocation, but there was a period where we considered having a ref reborrow tighten the available range. But even if normal reborrows don't subslice, those issues do come up with trying to handle an in-process allocator.

But that's IMHO no reason to complicate this for everybody else who isn't writing an allocator.