[Design] return char[] or string?

[Regan Heath]

Manfred Nowak wrote:
> Regan Heath wrote
> 
>> "Properties are member functions that can be syntactically treated
>> as if they were fields"
>>
>> 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.
> 
> For me the definition implies that fields can replace properties, but 
> no property can replace a field.
> 
> I read the definition above like this:
> : if a member function can be syntactically treated as a field, then 
> : it is a property

Sure, you can reverse the definition if you like.  The end result is 
that as there are no member functions in D which can be syntactically 
treated as if they were fields (in all cases) then D does not have 
properties by this definition.

Note I use "(in all cases)" above, that is the assumption I am making, 
if any.  I believe this assumption is implied by the definition, just as 
I believe your assumption below is not.

> i.e.,  properties have less syntactical power than fields.

This is certainly true, but how do you draw that conclusion from the 
definition? (this is not the assumption to which I refer above)

> 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.

It seems you are giving us a new defintion for properties in D which 
reads something like:

"properties are member functions with at most one formal parameter 
(which) can be treated as fields in assignments only"


Lets take a look at the full text of the paragraph in the docs 
containing the definition of a property:

"Properties are member functions that can be syntactically treated as if 
they were fields. Properties can be read from or written to. A property 
is read by calling a method with no arguments; a property is written by 
calling a method with its argument being the value it is set to."

Where does the definition mention only supporting assignments? (this is 
your assumption)

Where does it mention "at most one formal parameter"?

> All those recognizable errors in yours and Stewart's examples are 
> based on the wrong assumption, that properties are more powerful than 
> fields.

It's possible my assumption "that properties should be treated 
syntactically like fields (in all cases)" is incorrect but given the 
core purpose of properties (to replace fields seamlessly) I don't think 
it's an outrageous assumption to make.

I am simply expecting to be able to treat properties as fields 
(syntactically speaking) which is (almost to the letter/word) exactly 
what the definition states.

We can quible over the definition all we like and frankly I don't really 
care to.  We all know the docs are seldom precisely defined nor do they 
necessarily reflect reality.

The simple fact remains that just about every new D user writes:

char[] p;
p.length += 5;

and expects the 'length' "property" to be incremented by 5.

Unless the error cases mentioned are supported by properties then the 
core reason for having properties (being able to seamlessly refactor 
replacing a field with a property) is null and void as it will regularly 
result in changes being required to user code.

Properties are not as useful as many of us wish they were.

I assume you agree that it would be quite nice to be able to use 
properties in the error cases listed?

Regan