[Design] return char[] or string?

[Stewart Gordon]

"Manfred Nowak" <svv1999 at hotmail.com> wrote in message 
news:faki47$2ifr$1 at digitalmars.com...
> Regan Heath wrote
>
>> "Properties are member functions that can be syntactically treated
>> as if they were fields"

What I think it means is simply that you can get/set a property with 
notation that looks as though you're getting/setting a field.

>> I was under the impression the main benefit to properties was
>> being able to replace an existing field (one in use by some user
>> code) with a property and have it work without user code changes.

I think that's more or less what was meant to happen, but it hasn't quite 
turned out that way.

> For me the definition implies that fields can replace properties, but
> no property can replace a field.

I don't see how you work that out.

> I read the definition above like this:
> : if a member function can be syntactically treated as a field, then
> : it is a property
> i.e.,  properties have less syntactical power than fields.
>
> Because member functions with at most one formal parameter can be
> treated as fields in assignments, i.e. without the parentheses, D has
> properties according to the definition in the docs.
>
> All those recognizable errors in yours and Stewart's examples are
> based on the wrong assumption, that properties are more powerful than
> fields.

I suppose properties have less syntactical power, but more power in terms of 
practical uses.  If that makes sense....

Stewart.