Make ^ the unsafe-pointer sigil, * the region-pointer sigil.

[graydon]

Since most of our signatures will carry region-pointers we might as well make them look as much like "pointer" as any programmer's visual reflex will give. We also have to do something about the ambiguity between & as a sigil and & as an operator (explained by niko's post about patterns that capture values by reference).

It requires freeing up * from unsafe-pointer duty, so we're going to use ^ there, in a nod to pascal I guess, or maybe just due to it being "pointy looking" and thus hazardous-seeming.

Anyway, onwards through the syntax bikeshed jungle!

[brson]

So when we do this, how are you going to create pointers?

let x: @int = @0;
let y: ~int = ~0;
// I would expect this
let z: *int = *0;
// But is this what we're going to get?
let z: *int = &0;

[graydon]

Yes, let z: *int = &0;

I must admit to not liking this asymmetry. I'm not sure what to do instead. The whole thing arises because the & operator isn't merely a value constructor; there are two possible things we can imagine it meaning in patterns: take-a-pointer or match-existing-pointer. We have to choose which of those to make it mean. We can make one of the following code scenarios work, but only if we sacrifice the other.

  alt foo { bar(&x) { ... } }  // take-a-pointer to x
  alt foo { baz(*x) { ... } }  // match-existing-pointer, deref
  let quux : *x = &10;         // but yuck, type constructor != expr operator
  let &garply = 10;            // garply is type *int, pointing to 10

  alt foo { bar(*x) { ... } }  // take-a-pointer to x
  alt foo { baz(&x) { ... } }  // match-existing-pointer, deref
  let quux : &x = &10;         // but ahh, type constructor == expr operator
  let *garply = 10;            // also type &int, pointing to 10, but even less intuitive?

The former reads more like C, the latter reads more like Cyclone. Weirdly, if we go with the first it will also be possible to write let &x = 10; to mean the same thing as let x = &10;

Given these, I tend to agree with @nikomatsakis that the C-style (as this bug is aiming for) is the "lesser evil". Any strong opinions either way?

[brson]

There is also this:

  alt foo { bar(&x) { ... } }  // take-a-pointer to x
  alt foo { baz(^x) { ... } }  // match-existing-pointer, deref
  let quux : ^x = ^10;         // but ahh, type constructor == expr operator
  let &garply = 10;

With * as the unsafe pointer. Since there's no way to construct a value into an unsafe pointer, that doesn't have the problem for *, while keeping the parallels with the heap pointers. I think.

[graydon]

It's possible (and I certainly prefer ^ as the safe-ref sigil, leaving * as unsafe-ptr) though ... would & exist as an expression operator at all in that case? In what I was proposing earlier, it would; in what you just wrote here, it looks like it only exists in pattern position.

[brson]

I kind of like using a different sigil for pattern matching. I don't understand exactly why we need to be able to take arbitrary pointers to the inside of patterns anyway - isn't that what pattern bindings do already?

alt x { &y { } }
alt x { y { } }

Don't both these just create a pointer to x named y?

[graydon]

No, patterns are to become value-copying, so the former would either treat x as a pointer and copy-out the pointee or take-a-reference to x; and the latter would make a copy of x.

We're discussing this more on IRC because part way through the change, it is looking uglier and uglier to follow the path proposed here. Maybe *-in-patterns is the lesser evil after all.

[graydon]

Ok, consensus that we had this figured out at its least-painful setting back in the first two messages of the thread:

https://mail.mozilla.org/pipermail/rust-dev/2012-June/001935.html
https://mail.mozilla.org/pipermail/rust-dev/2012-June/001936.html

And that we should, therefore, follow this plan:

• Leave & meaning borrowed-reference and * meaning unsafe-pointer. Matches C++ intuitions.
• Introduce ref as a keyword for binding-by-reference in a pattern.
• Make & as a pattern mean match-a-borrowed-reference.

So be it! Least work and makes C++ people comfortable. Done. Backing out the ^ stuff and closing this bug!

[cpeterso]

btw, Microsoft's Managed C++ and C++/CLI use ^ for safe pointers and * for unsafe pointers, so that is another (admittedly weak :) precedent supporting your final decision to not use ^ for unsafe pointers.