struct Foo
{
    @property int data() { return m_data; } // read property
    @property int data(int value) { return m_data = value; } // write property
    private: int m_data;
}

It would be nice if properties had an internal variable to use instead of having to declare it explicitly:


struct Foo
{
    @property int data() { return data.value; } // read property
    @property int data(int value) { return data.value; } // write property
}

This reduces code complexity. If a property does not use the internal variable(which I signify by .value) then it does not add any storage. This allows one to easily wrap fields into properties without having to create private fields for each property unless needed.

On Monday, July 01, 2013 03:22:15 JS wrote:
> struct Foo
> {
>      @property int data() { return m_data; } // read property
>      @property int data(int value) { return m_data = value; } //
> write property
>      private: int m_data;
> }
> 
> It would be nice if properties had an internal variable to use instead of having to declare it explicitly:
> 
> 
> struct Foo
> {
>      @property int data() { return data.value; } // read property
>      @property int data(int value) { return data.value; } // write
> property
> }
> 
> This reduces code complexity. If a property does not use the internal variable(which I signify by .value) then it does not add any storage. This allows one to easily wrap fields into properties without having to create private fields for each property unless needed.

I believe that the way that this sort of enhancement has typically been suggested is to do something like

public @property int value;

which would be lowered to something like

public @property int value() @safe const pure nothrow { return _value; }
public @property int value(int v) @safe pure nothrow { return _value = v; }
private int _value;

And I think that that's clearer than your suggestion (it's definitely shorter). It also doesn't require the compiler to infer anything about whether you meant to have it create a variable or not. It simply tells the compiler what to do in a more concise manner.

- Jonathan M Davis

On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:
> On Monday, July 01, 2013 03:22:15 JS wrote:
>> struct Foo
>> {
>>      @property int data() { return m_data; } // read property
>>      @property int data(int value) { return m_data = value; } //
>> write property
>>      private: int m_data;
>> }
>> 
>> It would be nice if properties had an internal variable to use
>> instead of having to declare it explicitly:
>> 
>> 
>> struct Foo
>> {
>>      @property int data() { return data.value; } // read property
>>      @property int data(int value) { return data.value; } // write
>> property
>> }
>> 
>> This reduces code complexity. If a property does not use the
>> internal variable(which I signify by .value) then it does not add
>> any storage. This allows one to easily wrap fields into
>> properties without having to create private fields for each
>> property unless needed.
>
> I believe that the way that this sort of enhancement has typically been
> suggested is to do something like
>
> public @property int value;
>
> which would be lowered to something like
>
> public @property int value() @safe const pure nothrow { return _value; }
> public @property int value(int v) @safe pure nothrow { return _value = v; }
> private int _value;
>
> And I think that that's clearer than your suggestion (it's definitely shorter).
> It also doesn't require the compiler to infer anything about whether you meant
> to have it create a variable or not. It simply tells the compiler what to do
> in a more concise manner.
>
> - Jonathan M Davis

But yet absolutely useless and does nothing over using a field directly.

If you are worried about the compiler not being able to infer if an internal variable needs to be used or not(which is kinda ridiculous because it is very simple to do so(if propertyname.value is used then there needs to be an internal variable, else not), one can just use a new keyword/attribute @propertyval or something...

On 07/01/2013 03:22 AM, JS wrote:
> struct Foo
> {
>      @property int data() { return m_data; } // read property
>      @property int data(int value) { return m_data = value; } // write
> property
>      private: int m_data;
> }
>
> It would be nice if properties had an internal variable to use instead
> of having to declare it explicitly:
>
>
> struct Foo
> {
>      @property int data() { return data.value; } // read property
>      @property int data(int value) { return data.value; } // write property
> }
>
> This reduces code complexity. If a property does not use the internal
> variable(which I signify by .value) then it does not add any storage.
> This allows one to easily wrap fields into properties without having to
> create private fields for each property unless needed.

struct S{
    T value;
}

struct T{
    S get(){ return S(this); }
    alias get this;
}

struct Foo{
    @property S data(){ return data.value; }
}

On 7/1/13, JS <js.mdnq@gmail.com> wrote:
> But yet absolutely useless and does nothing over using a field directly.

Not completely useless, this syntax would theoretically disallow taking the address of such a field.

On Monday, July 01, 2013 04:03:41 Andrej Mitrovic wrote:
> On 7/1/13, JS <js.mdnq@gmail.com> wrote:
> > But yet absolutely useless and does nothing over using a field directly.
> 
> Not completely useless, this syntax would theoretically disallow taking the address of such a field.

Yeah. public fields and property functions are _not_ interchangeable, much as we'd like them to be. By going with what I suggested, you get the short syntax of declaring a variable, but you end up with actual functions so that you don't have issues with later swapping the field out with property functions that you write yourself when you decide that you need them to do more.

- Jonathan M Davis

W dniu 01.07.2013 03:35, Jonathan M Davis pisze:
> On Monday, July 01, 2013 03:22:15 JS wrote:
>> struct Foo
>> {
>>       @property int data() { return m_data; } // read property
>>       @property int data(int value) { return m_data = value; } //
>> write property
>>       private: int m_data;
>> }
>>
>> It would be nice if properties had an internal variable to use
>> instead of having to declare it explicitly:
>>
>>
>> struct Foo
>> {
>>       @property int data() { return data.value; } // read property
>>       @property int data(int value) { return data.value; } // write
>> property
>> }
>>
>> This reduces code complexity. If a property does not use the
>> internal variable(which I signify by .value) then it does not add
>> any storage. This allows one to easily wrap fields into
>> properties without having to create private fields for each
>> property unless needed.
>
> I believe that the way that this sort of enhancement has typically been
> suggested is to do something like
>
> public @property int value;
>
> which would be lowered to something like
>
> public @property int value() @safe const pure nothrow { return _value; }
> public @property int value(int v) @safe pure nothrow { return _value = v; }
> private int _value;

This is nice, and this pattern promotes overriding of properties.

> And I think that that's clearer than your suggestion (it's definitely shorter).
> It also doesn't require the compiler to infer anything about whether you meant
> to have it create a variable or not. It simply tells the compiler what to do
> in a more concise manner.

Yes, it's clearer and more importantly it doesn't hide aggregate fields inside methods. Data layout of an aggregate should be clear IMHO.

On 06/30/2013 06:43 PM, JS wrote:

>> On Monday, July 01, 2013 03:22:15 JS wrote:
>>> struct Foo
>>> {
>>>      @property int data() { return m_data; } // read property
>>>      @property int data(int value) { return m_data = value; } //
>>> write property
>>>      private: int m_data;
>>> }
>>>
>>> It would be nice if properties had an internal variable to use
>>> instead of having to declare it explicitly:
>>>
>>>
>>> struct Foo
>>> {
>>>      @property int data() { return data.value; } // read property
>>>      @property int data(int value) { return data.value; } // write
>>> property
>>> }
>>>
>>> This reduces code complexity.

I have the complete opposite view: Seeing what m_data explicitly in the code would be simpler than reading code to see that data.value would mean implicit storage.

> (if propertyname.value is used then
> there needs to be an internal variable, else not),

Where would the compiler make room for that variable in relation to the other members? With programming languages, explicit is almost always better than implicit.

Ali

On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:
> On 06/30/2013 06:43 PM, JS wrote:
>
> >> On Monday, July 01, 2013 03:22:15 JS wrote:
> >>> struct Foo
> >>> {
> >>>      @property int data() { return m_data; } // read
> property
> >>>      @property int data(int value) { return m_data = value;
> } //
> >>> write property
> >>>      private: int m_data;
> >>> }
> >>>
> >>> It would be nice if properties had an internal variable to
> use
> >>> instead of having to declare it explicitly:
> >>>
> >>>
> >>> struct Foo
> >>> {
> >>>      @property int data() { return data.value; } // read
> property
> >>>      @property int data(int value) { return data.value; }
> // write
> >>> property
> >>> }
> >>>
> >>> This reduces code complexity.
>
> I have the complete opposite view: Seeing what m_data explicitly in the code would be simpler than reading code to see that data.value would mean implicit storage.
>

huh? There is absolutely no semantic difference between the two. The proposed case is easier because the field can't be hidden away somewhere making it hard to find.

@property T x() { }

represents a function and possibly a variable of type T. You know that by looking at the property. It is not a hard leap to understand.

The old way:

@property T x() { }
T _x;

Is more verbose, and verbose is not always better. If your class as many variables and some are hidden then it could be difficult to know where the variable is.

If the field is not of the same type then either the original method can be used or possibly an extension:

@property T:W x() { return x.value.t; }

represents the same as

@property T x() { return _x.t; }
W _x;

There is absolutely no difference in semantics... just syntax. One is more verbose. It shouldn't be difficult to see that.

It's no different than writing separate setters and getters... no difference... just they are more verbose. If you are against my suggestion you should be against properties in general because they are a simplification of such.

> > (if propertyname.value is used then
> > there needs to be an internal variable, else not),
>
> Where would the compiler make room for that variable in relation to the other members? With programming languages, explicit is almost always better than implicit.
>
> Ali

huh? The exact same place it does so if the programmer explicitly adds it. It's location in the class my not be the same but that is, in general, irrelevant unless you are messing with the bits of the class.

On 2013-07-01 03:43, JS wrote:

> But yet absolutely useless and does nothing over using a field directly.

The advantage is that you get virtual methods. I also think it should be possible to manually implement just the setter, or getter. The compiler would only generate what's not already present.

-- 
/Jacob Carlborg