decide on official naming conventions for ~, @, & and *

[thestinger]

We use really inconsistent naming at the moment: unique/owned/managed pointers/boxes, borrowed/region pointers, unsafe/raw pointers.

Some thoughts on the possibilities:

&:

• reference - simple, implies that it points at an existing object and talks about semantics rather than implementation and we already have ref and ref mut
• borrowed pointer - intimidating, but also does a good job conveying that it's a reference to existing memory and it's the defacto name right now

~ and @:

Owned/managed pointer isn't correct since the pointer itself is just a handle - all pointers are owned, but not necessarily what they point at. That's part of why we got into the convention of calling them boxes.

So we should settle on one of these:

• unique/managed pointer
• owned/managed box

*:

• raw pointer
• unsafe pointer

I think I would be happiest with "reference", "unique pointer", "managed pointer" and "raw pointer" but I'm sure there are other opinions :). I just want to get the documentation consistent with standardized terms....

[glaebhoerl]

IMHO:

&: borrowed reference, can be abbreviated to just "reference"
~: owned box
@: managed box
*: pointer

IOW the name "pointer" would be reserved for pointers in the C sense. This is consistent with other languages I'm aware of (such as D), where the word "pointer" inherently carries the connotation of being unsafe, and the safe part of the language is distinguished by not having them. & is quite similar to C++ references, anyways.

[ben0x539]

I think it's almost misleading to call ~ and @ boxes and not pointers (or at least handles). Sure, from the type system perspective, the interesting bit is the behavior of box they point at, but it seems nicer to me to talk about them in terms of what you get in your stack frame or inside your struct when you declare one, that is, to say that let x = @42 makes x a pointer to a boxed 42 rather than that it is a box that happens to live behind a pointer indirection or something weird like that, and if you say let y = x; you don't suddenly have two boxes, just two pointers. Or handles.

Anyway, I kind of like the "owned"/"shared" dichotomy, and it's not really inaccurate to say that ~T and @T are owning and sharing pointers to owned and shared boxes, respectively.

"Reference" feels weird. Calling it a reference more clearly delineates it from ~/@ but the "borrowing" verbage is probably not going anywhere in either case, so it might as well stay in the name, and "borrowed" fits in nicely with "owned"/"shared".

I like "unsafe pointer" because it conveys that you're on your own with regards to convincing yourself that it's okay to dereference it. "Raw" doesn't really imply much beyond maybe not being as fully-featured as the other, cooked pointer types, but "unsafe" sort of suggests that you get to do all that uninhibited offsetting and casting and whatever you might feel the need to do as a C programmer without the compiler looking over your shoulder. Though if we end up calling all the other ones something besides pointer, that's moot.

Sorry, that's a bit rambling, but I felt like I needed to get my two cent in before this bikeshed departs for good.

[glaebhoerl]

(FWIW if you wanted to refer to just the handle of the box I would say owned/owning/unique and managed reference. "Reference" is to distinguish it not from @ and ~ but from *, following the same logic that only pointers (as the rest of the world knows them) should be called pointers.)

[huonw]

I'd (weakly) vote against * being plain "pointer", since giving these use-as-a-last-resort pointers the most common name could possibly mean that they get more use than they should. "unsafe pointer" is nice, because it emphasises the danger.

[steveklabnik]

My vote:

~: unique pointer (alternative: the 'highlander pointer' 😉 )
@: managed pointer
&: borrowed pointer. It makes it easy to explain in terms of ~ and @.
*: unsafe pointer, emphasizes the danger

[rapha]

+1 to the unique, managed, borrowed and unsafe qualifiers.

[thestinger]

By the way the reasoning beyond the suggestion to use raw is that it's not wrapped/abstraction away. Treating them as integers is safe up until the point that you dereference them, which isn't much different than using unsafe array indexing with uint.

[thestinger]

Bumping for bug triage, this is still inconsistent across the documentation.

[bstrie]

My vote:

&: reference
~: unique pointer
*: raw pointer

Hopefully moving @ into the stdlib should obviate the need to have a special name for it.

[emberian]

The terminology that has won me over is:

&: borrowed pointer (although I also like "reference", many others seem to not)
~: owning pointer, points to an owned box.
*: raw pointer

[thestinger]

This is too out-of-date to be relevant. Managed pointers are no longer part of non-gated language, and @mut has in fact been entirely removed. Renaming borrowed pointers to references has already begun.