www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UDP enhancement

reply "JS" <js.mdnq gmail.com> writes:
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.
Jun 30 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 30 2013
next sibling parent reply "JS" <js.mdnq gmail.com> writes:
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...
Jun 30 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 30 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jun 30 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jun 30 2013
parent reply "JS" <js.mdnq gmail.com> writes:
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.
Jun 30 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/30/2013 08:54 PM, JS wrote:


 On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:



 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.


Agreed. I find implicit storage making code more complex.


 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.


Agreed but I was talking about understanding the implementation, not the 
API. When a function returns data.value, it returns the 'value' member 
of a variable 'data'. Where is 'data'? Not a local variable. Not a 
member? A global? Oh! I wonder? Yes, it is an implicit member that is 
created by the compiler.

Note the old proposal that Jonathan has reminded us about does not have 
that problem. It is obvious that we are looking at a property.


 The old way:

  property T x() { }
 T _x;

 Is more verbose, and verbose is not always better.


Agreed in general but not in this case.


 If your class as many
 variables and some are hidden then it could be difficult to know where
 the variable is.


That is always possible and requires discipline and coding guidelines. 
The programmers must know to communicate ideas and designs.


 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.


I am not against how they make syntax easier. I don't need to prefix 
function names by get_ or set_ and I don't need to use parentheses.


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


How can the compiler put it in *the exact spot* if I am not adding it 
explicitly? Are you suggesting that such functions be inserted between 
other member variables?

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

What if there is another member between these special functions? 
Compiler error?


 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.


I was thinking about structs.

Ali
Jul 01 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Monday, 1 July 2013 at 16:24:40 UTC, Ali Çehreli wrote:

 On 06/30/2013 08:54 PM, JS wrote:


 On Monday, 1 July 2013 at 02:17:24 UTC, Ali Çehreli wrote:



 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.

 Agreed. I find implicit storage making code more complex.


(Well, I'm sure some will find it useful in some cases and I 
don't think such a case could hurt much but I'd probably never 
use it)


 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.

 Agreed but I was talking about understanding the 
 implementation, not the API. When a function returns 
 data.value, it returns the 'value' member of a variable 'data'. 
 Where is 'data'? Not a local variable. Not a member? A global? 
 Oh! I wonder? Yes, it is an implicit member that is created by 
 the compiler.

 Note the old proposal that Jonathan has reminded us about does 
 not have that problem. It is obvious that we are looking at a 
 property.


Well, I personally don't care what symbols or syntax you want to 
use(well, within reason). I used a common syntax because it is 
something people are familiar with. To me it is nitpicking 
because it has nothing to do with the real issue. It's not the 
syntax that is under question but the concept/implementation.

What's important to me is to not have to create a private field 
every time I want to create a property. It seems like a waste of 
time and is verbose for no reason. It doesn't confuse me one bit 
to "hide" the field in the property because essentially that's 
what properties do(to the user of the property)... So it doesn't 
change anything from the outside and only goes to reduce your 
code size.


 The old way:

  property T x() { }
 T _x;

 Is more verbose, and verbose is not always better.


 Agreed in general but not in this case.


 If your class as many
 variables and some are hidden then it could be difficult to


 know where

 the variable is.


 That is always possible and requires discipline and coding 
 guidelines. The programmers must know to communicate ideas and 
 designs.


Yes, but any programming language is there to simplify... If we 
had infinite memories and intelligence then direct machine 
language(hex) would be just fine.

IMO by removing excess and essentially useless text in source 
code makes it easier to follow and maintain. Almost all 
programming constructs do this... sometimes it's their sole 
purpose(a macro, function, struct, etc...). (encapsulation of 
data/code is mainly to simplify complexity and not for 
security/safety)


 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.


 I am not against how they make syntax easier. I don't need to 
 prefix function names by get_ or set_ and I don't need to use 
 parentheses.


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


 How can the compiler put it in *the exact spot* if I am not 
 adding it explicitly? Are you suggesting that such functions be 
 inserted between other member variables?


I'm not sure we are are talking about the same thing:


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

 What if there is another member between these special 
 functions? Compiler error?


 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.

 I was thinking about structs.

 Ali



struct Foo
{
     // int data.value; "inserted here"
     int m;
     // int data.value; or here
      property int data() { return data.value; } // read property
     // int data.value; or here
 property int data(int value) { return data.value = value; } // 
write property
     // int data.value; or here
     double d;
     // int data.value; or here

}

vs

struct Foo
{
     int m;
      property int data() { return val; } // read property
      property int data(int value) { return val = value; } // 
write property
     double d;
     private int val;
}


It will almost never matter where the compiler inserts the hidden 
variable for us except when "hacking" the struct(which, as long 
as it's consistent, it shouldn't matter.

to me, the first case is more concise but does EXACTLY the same 
thing. I like things to be concise. I don't wanna see crap that I 
don't need to see. In the 2nd case, val is only required because 
the compiler is not smart enough. We can easily write a 
preprocessor to do the above(in fact, I've done it before).
Jul 01 2013
parent reply "estew" <estewh gmail.com> writes:
 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.




Actually we do this a lot in C++ where I work to ensure proper 
alignment. We are also starting to do this in D where we have C++ 
<-> D bindings so we can make our D structs exactly match our C++ 
structs in memory.

Personally I see less benefit over:

public  property int value;

This approach is nice. It can be used both when layout is 
important and when it is "don't care" and is clearer. I can look 
at the struct and immediately read its memory footprint.

Your suggested proposal cannot be used when layout is important 
as it is left to the compiler. It would require a workaround to 
coerce the compiler into submission, or additional compiler 
circuitry making it even more complex and slowing it down.
Jul 01 2013
parent "JS" <js.mdnq gmail.com> writes:
On Tuesday, 2 July 2013 at 04:49:55 UTC, estew wrote:

 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.




 Actually we do this a lot in C++ where I work to ensure proper 
 alignment. We are also starting to do this in D where we have 
 C++ <-> D bindings so we can make our D structs exactly match 
 our C++ structs in memory.

 Personally I see less benefit over:

 public  property int value;

 This approach is nice. It can be used both when layout is 
 important and when it is "don't care" and is clearer. I can 
 look at the struct and immediately read its memory footprint.

 Your suggested proposal cannot be used when layout is important 
 as it is left to the compiler. It would require a workaround to 
 coerce the compiler into submission, or additional compiler 
 circuitry making it even more complex and slowing it down.


Or just use the old way. Just because one extends a feature does 
not mean the old feature is removed. If you need to hack up the 
bits just explicitly allocate the field... simple as that.
Jul 02 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 01 2013
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
Jun 30 2013
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:

 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;

 - Jonathan M Davis


As someone who uses properties almost everywhere, and almost 
never uses public fields, this is one of my biggest gripes with D 
remaining. It's incredibly annoying to have to do things like

private int _width;
/// Gets or sets the total width, in pixels, of this control.
 property int width() const {
     return _width;
}
/// ditto
 property void width(int value) {
     this._width = value;
}


Something like

/// Gets or sets the total width, in pixels, of this control.
 property const int width;

Is just so much nicer and saves so much bloat. I feel like the 
current property syntax is one of those places where IDE code 
snippets will start to become, not necessary, but extremely 
useful. It's the type of manual repetition that D aims to avoid, 
but in this case fails at.
I don't know if I agree with automatically expanding to const 
though. I'd like to be able to do ' property Control parent' 
without needing to return a const(Control) because the property 
is expanded to be const. Although if we had a virtual keyword, 
final is something that I think should be default for properties, 
and I think it's a mistake that the current  property doesn't 
infer final in the first place. Safe and nothrow are two 
assumptions that are probably quite safe to assume for the most 
part as well.
Jul 02 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 02, 2013 19:49:39 Kapps wrote:

 On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:

 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;
 
 - Jonathan M Davis


 
 As someone who uses properties almost everywhere, and almost
 never uses public fields, this is one of my biggest gripes with D
 remaining. It's incredibly annoying to have to do things like
 
 private int _width;
 /// Gets or sets the total width, in pixels, of this control.
  property int width() const {
 return _width;
 }
 /// ditto
  property void width(int value) {
 this._width = value;
 }
 
 
 Something like
 
 /// Gets or sets the total width, in pixels, of this control.
  property const int width;
 
 Is just so much nicer and saves so much bloat. I feel like the
 current property syntax is one of those places where IDE code
 snippets will start to become, not necessary, but extremely
 useful. It's the type of manual repetition that D aims to avoid,
 but in this case fails at.
 I don't know if I agree with automatically expanding to const
 though.


inout would probably be better then. But without that, anyone wanting to be 
const-correct is going to have to declare all of the getters themselves. inout 
isn't quite there, because there are many cases where you really do want to 
return const even when the object is mutable, but it would probably be a good 
compromise.

- Jonathan M Davis
Jul 02 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Kapps" <opantm2+spam gmail.com> wrote in message 
news:zroaabiwkaxqybrtdhxp forum.dlang.org...

 As someone who uses properties almost everywhere, and almost never uses 
 public fields, this is one of my biggest gripes with D remaining. It's 
 incredibly annoying to have to do things like

 private int _width;
 /// Gets or sets the total width, in pixels, of this control.
  property int width() const {
     return _width;
 }
 /// ditto
  property void width(int value) {
     this._width = value;
 }


 Something like

 /// Gets or sets the total width, in pixels, of this control.
  property const int width;

 Is just so much nicer and saves so much bloat. I feel like the current 
 property syntax is one of those places where IDE code snippets will start 
 to become, not necessary, but extremely useful. It's the type of manual 
 repetition that D aims to avoid, but in this case fails at.
 I don't know if I agree with automatically expanding to const though. I'd 
 like to be able to do ' property Control parent' without needing to return 
 a const(Control) because the property is expanded to be const. Although if 
 we had a virtual keyword, final is something that I think should be 
 default for properties, and I think it's a mistake that the current 
  property doesn't infer final in the first place. Safe and nothrow are two 
 assumptions that are probably quite safe to assume for the most part as 
 well.


You should probably try using template mixins, if all you need to do is 
expand some code.
Jul 02 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-07-03 03:42, Daniel Murphy wrote:


 You should probably try using template mixins, if all you need to do is
 expand some code.


I don't think that works so well together with ddoc comments. Ideally 
you should be able to do something like this:

class Foo
{
     /// Get/set bar
     mixin property!(int, "bar");
}

-- 
/Jacob Carlborg
Jul 05 2013
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:kr673g$179s$1 digitalmars.com...

 On 2013-07-03 03:42, Daniel Murphy wrote:


 You should probably try using template mixins, if all you need to do is
 expand some code.


 I don't think that works so well together with ddoc comments. Ideally you 
 should be able to do something like this:

 class Foo
 {
     /// Get/set bar
     mixin property!(int, "bar");
 }

 -- 
 /Jacob Carlborg


True, for now.
Jul 05 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/5/13, Jacob Carlborg <doob me.com> wrote:

 I don't think that works so well together with ddoc comments. Ideally
 you should be able to do something like this:

 class Foo
 {
      /// Get/set bar
      mixin property!(int, "bar");
 }


Related: https://github.com/D-Programming-Language/dmd/pull/1485

Although this pull does the opposite of what's requested here.
Jul 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-07-05 14:31, Andrej Mitrovic wrote:


 Related: https://github.com/D-Programming-Language/dmd/pull/1485

 Although this pull does the opposite of what's requested here.


In this case I don't think you want to show the methods the mixin 
expands to.

-- 
/Jacob Carlborg
Jul 06 2013
prev sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 3 July 2013 at 01:42:06 UTC, Daniel Murphy wrote:

 You should probably try using template mixins, if all you need 
 to do is
 expand some code.


https://github.com/D-Programming-Language/phobos/pull/1294
Jul 05 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:

 I believe that the way that this sort of enhancement has 
 typically been suggested


Oh hey, I remember the DIP23 madness.  Is it that time again 
already?


 is to do something like

 public  property int value;


Yes.  Please, yes.  This kills so much boilerplate.

(In fairness, DIP23 was pretty good, aside from the address-of 
shenanigans and lack of low-hanging operator rewrites.)

-Wyatt
Jul 05 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/05/2013 03:53 PM, Wyatt wrote:

 On Monday, 1 July 2013 at 01:35:40 UTC, Jonathan M Davis wrote:

 I believe that the way that this sort of enhancement has typically
 been suggested


 Oh hey, I remember the DIP23 madness.  Is it that time again already?


 is to do something like

 public  property int value;


 Yes.  Please, yes.  This kills so much boilerplate.

 (In fairness, DIP23 was pretty good, aside from the address-of
 shenanigans and lack of low-hanging operator rewrites.)

 -Wyatt


DIP24 FTW!
Jul 05 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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; }
}
Jun 30 2013