To remove syntax overloading for @, I'd like to make a separate proposal/discussion on the syntax for field storage access. For starters, I'd like to say that I love Fan's automatic field storage feature. Saves lots of pain. I also get that the @field syntax is inspired by Ruby, but I think an alternative would be better.

First here, are various options presented by Brian earlier (noting that some of these are otherwise boolean operators and that's okay):

Str name { set { @name = val } }
Str name { set { %name = val } }
Str name { set { #name = val } }
Str name { set { ^name = val } }
Str name { set { :name = val } }
Str name { set { .name = val } }

My proposal has a slightly different approach. I recommend this:

Str name { set { _name = val } }

Summary is that instead of using an operator, you just use the semi-common (yet also semi-antiquated) convention _field. If _field isn't already defined in the class, the compiler fills it in as a field storage slot.

If _field is already defined, then the compiler can't generate storage for you, and I think that's okay, too:

Str name {set {_name = val}}
private Str _name {set {__name = val.upper}} // or whatever

Again, this approach gives an explicit identifier to the storage slot rather than using an operator, but it also lets you customize another level deep should you so wish. In a sense, I think it takes some of the magic away, and I think the convention will perhaps be more familiar to Java/C# folks.

I really like the @ character for field storage. But even if we did change it, I think it has to be another non-identifier character.

_ is probably the only character that I would be opposed to seeing in this context, because it's a legal identifier character in most languages.

@ and : are the best candidates in my opinion (betraying my Ruby background), so I'm in favor of the status quo (@).

The @ symbol here is one I felt comfortable with on first reading it, so its not something I'd immediately argue to change.

Based on opinions here, I vote for :name if we need to liberate @ for other expressions (which I still hope to do).

Using _ is a neat idea, but it is really relying on semantics based on a naming convention not an operator which I don't like. Or maybe you were proposing that _ not be allowed in identifiers which I don't consider feasible.

I like @ best and don't really want to change it.

However Tom makes an excellent point that @ is overloaded for use by both facets and field storage. This might cause us serious headaches in the future if we ever decided we needed to something like facets on local variables (not that I'm saying that is a good idea). But it does seem somewhat prudent to select another operator which isn't confused with the facet syntax (damn I hate how few symbols are on the keyboard).

I'd be interested in hearing more opinions on that future proofing.

If we did change it then my next choice is ^ as the field storage operator.