Two recent changes have freed up a bunch of symbols:

• the final facet design freed up @
• removal of the bitwise operators freed up &, |, ^, and ~

The original field storage operator was @, and was changed to * to make way for the failed symbol experiment. It is not a good choice because it conflicts with the * binary multiplication operator and can cause line ending ambiguity.

See previous discussions on the topic: 317

So the question is do we want to change the storage operator? And should we change it back to @ or use something else?

Either @ or & would be fine.

The & operator looks like the address operator in C. "Address" and "storage" are similar, and it might help as a mnemonic.

The @ operator is fine too. It's very close to Ruby's private slot marker.

Agreed, either @ or & would be fine, maybe a preference for the latter (might allow Email literals!).

Aren't email literals just a subset of URIs?

Now that & is freed up, I lean towards using that.

I find C address operator syntax quite convenient too.

No special preference; I miss the curry operator sometimes tho...

@KevinKelley: me too. Even having Func.curry back would be nice.

Now that & is freed up, I lean towards using that.

Sounds like their more support for & than using @. Sound we consider that a final decision?

Even having Func.curry back would be nice.

That didn't go away, just got renamed to sys::Func.bind

Promoted to ticket #1073 and assigned to brian

No more feedback, so I'll assume everybody is happy with & as the new storage operator.

Ticket resolved in 1.0.53

Using * as the field storage operator will produce a warning for build 53, and will be removed in 54. The & symbol is now used as the field storage operator.