DIP4: Properties

[Daniel Keep]

Some comments:

There should be an actual proposal definition instead of just an
example.  Examples tend to be misinterpreted.

I've tried to work out a possible grammar:

Decl:
	BasicType DeclaratorInitializer '{' PropertyDecls '}'

PropertyDecls:
	PropertyDecl
	PropertyDecl PropertyDecls

PropertyDecl:
	PropertyIdentifier BlockStatement

PropertyIdentifier:
	'get'
	'set'

(note: additions to this grammar are below)

---

The "optimise implicit value away" thing is a bit iffy.  I'd prefer some
actual syntactic distinction between a property with automatic storage.
 It would be far too easy to accidentally cause the backing to be added.

I had the following idea, but I'm worried that it's context-sensitive;
it looks an awful lot like a normal AutoDeclaration, except that it's
missing the assignment.  Mayhap someone with stronger grammar-fu could
tell me? :D

We could add the following:

PropertyDecl:
	'auto' Identifier ';'

If this appears in a property, it creates a private variable with the
same type as the property itself, scoped to the property declaration.
This would allow for people to use whatever "magic" name they like.
Your first example property would become:

int width = int.init
{
    auto value;
    get { return value; }
    set { value = set; }
}

---

Also, having the value being assigned to the property be called "set" is
really unnerving.  We've already got to explain to people why in
templates you "assign" to the name of the template; I don't want to have
to explain that it works in completely the opposite way for property
setters.  I think the solution to this is to just make it explicit
somehow.  `set(v) { value = v; }` is not THAT much more typing (minimum
of 3 characters), and it saves you from having to memorise yet another
magic identifier.

---

Q: How do properties interact with templates?

---

Being able to modify a read-only property is just *nasty*.  Having
either explicit backing or protection attributes on the getter/setter
would be a better solution.

Change PropertyDecl to:

PropertyDecl:
	PropertyIdentifier BlockStatement
	ProtectionAttribute PropertyIdentifier BlockStatement

---

Q: Is this syntax context-free?  I can't think of any existing case it
would conflict with.  Wish there was some easy way to check.

---

One issue I have with rewriting {a.b op= c} to {a.b = a.b op c} is that
the former may be much more efficient than the latter.  It might perhaps
be wise to postpone addressing this until later [1].

---

Some time ago, Andrei indicated that he felt properties needed *three*
basic operations: get, swap and delete, or something.  We should find
that post and look at whether it's a good idea.

---

Q: Why is 'delete' or 'remove' not available?  It's present in Python
(as an example), why not here?


[1] Personally, I suspect it would be best if we had a pragma or
something that told the compiler "look, even if this is a property,
don't rewrite it; I'll take care of it."  That, or maybe rewrite {a.b
op= c} to {auto tmp = a.b; tmp op= c; a.b = tmp}.