www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP23 Counter Proposal

reply Timon Gehr <timon.gehr gmx.ch> writes:
As my posts in the DIP23 thread have been left unanswered, I have 
prepared a counter proposal for DIP23 during the last hour.

Everything DIP23 addresses is specified in the two short sub-sections 
"Optional parens" and " property: basic design".

Those in favour of what was called "semantic rewrites" in the DIP23 
thread should probably read on further.

All parts of this proposal are independent of DIP24 (which Andrei is 
preparing).

http://wiki.dlang.org/DIP23_Counter_Proposal

There are almost no examples yet, but in case it is not clear how some 
case would be handled, feel free to ask.


(Also feel free to fix the formatting.)
Feb 05 2013
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 As my posts in the DIP23 thread have been left unanswered, I have  
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections  
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23  
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is  
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some  
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

Has my vote. For what it's worth :) One thing that should be clarified, you should explicitly say "member function (static or instance)" instead of just member function. The "optional this" kind of takes care of it, but you have to read it carefully to get that. I think it should be more straightforward. -Steve
Feb 05 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 02:20 AM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

Has my vote. For what it's worth :)

Thanks! :) The full proposal or just the basic design part? (I think the full "semantic rewrite" idea may have some issues regarding excessive postblit/destruction, so I am not entirely sure if it is a good idea, but it was requested.)
 One thing that should be clarified, you should explicitly say "member
 function (static or instance)" instead of just member function.  The
 "optional this" kind of takes care of it, but you have to read it
 carefully to get that.  I think it should be more straightforward.

 -Steve

Done. Another thing that was not specified yet was what the compiler is supposed to do when it encounters overloads where some are property and some are not. (I have added "It is illegal to overload property-qualified functions against non- property-qualified functions.")
Feb 05 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 03:45 AM, Steven Schveighoffer wrote:
 ...

 There are a couple of clarifications I was curious about:

 1. Does &prop work?  If so, what does it do?

It attempts to take the address of the result of the getter call.
 1a. if &prop doesn't work, does &__traits(propertyAccessors, prop) work
 (and give you the delegate to the property function overload set)?  I
 can only imagine this is the reason you have the rewrite to a __traits
 call...

Yes, exactly, &__traits(propertyAccessors, prop) gives delegate/function pointer access to the property function overload set.
 2. Inside the rules for when you do prop = exp, you specify that if the
 return is void, the expression is rewritten as
 (__traits(propertyAccessors, prop)(exp), prop).  I see some issues with
 this:
     2a. If you are NOT using the expression beyond the assignment, why
 call the accessor again?
     2b. This would preclude write-only properties (as the second element
 of the comma expression is invalid).  Is that intentional?

Not really. Good catch. Refined.
     2c. What about ref returning properties?  In those cases, the
 rewrite should be __traits(propertyAccessors, prop)() = exp;

I had forgotten to specify this. (The setter rewrite should be performed only if it makes sense.) I also had forgotten to treat alias declarations and template alias parameters. This is fixed now as well.
Feb 05 2013
prev sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
 ...

 The semantic rewrite stuff is something I don't feel strongly either
 way. It would be nice, but at the same time, it doesn't feel necessary
 to me. One can always simply avoid it by not using the operators on
 properties.

A core feature of properties is that variables can be migrated to them (and back) without breaking any of the caller's code. Forbidding more than half of D's operators on them will definitely break this attribute.
Feb 06 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 07, 2013 10:02:41 Steven Schveighoffer wrote:
 On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan <chadjoan gmail.com> wrote:
 On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
 ...
 
 The semantic rewrite stuff is something I don't feel strongly either
 way. It would be nice, but at the same time, it doesn't feel necessary
 to me. One can always simply avoid it by not using the operators on
 properties.

A core feature of properties is that variables can be migrated to them (and back) without breaking any of the caller's code. Forbidding more than half of D's operators on them will definitely break this attribute.

I find this explanation lacking. A field supports operations that are impossible to implement with properties, there will never be a non-code-breaking change from a field to a property. So it's a matter of "how much" breakage you want to allow. This is really a judgment call, there is no "right" answer. The closest you can get to a field is to ref an actual field. But in that case, I don't see the point of the property, since you give unfettered access to the field! The whole point of having properties that I see is to implement things you CAN'T implement with a field, or are more cumbersome. Like read-only fields. Such a change would necessarily and on purpose break code.

It works as long as you can limit the variable in some way. But I believe that the main purpose in using public variables rather than actual property functions when all they would do is get or set the variable is to avoid lots of boilerplate code. It's incredibly common to get stuff like struct S { int i() safe const pure nothrow { return _i; } int i(int value) safe pure nothrow { return _i = value; } private int _i; } That's a lot of extra code whose only benefit is encapsulation. So, it would be great if you could just do struct S { int i; } And with the ability to replace the variable with a property function later if it ever needs to do more than just get or set makes it so that encapsulation isn't a problem - except for the fact that there are certain operations that you can do on a variable that you can't do on a property function (e.g. taking its address or passing it by ref). Simply making it so that doing struct S { property int i; } lowered into something like the first example would allow you to avoid all of that boilerplate code and still have full encapsulation. It's definitely true that you can never make a property function completely emulate a variable, but all of the boilerplate required for simple getters and setters is kind of ridiculous. I believe that avoiding that is the primary reason that people want to be able to swap between variables and property functions, and with a small addition to the language, we can obviate that boilerplate. - Jonathan M Davis
Feb 07 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 struct S
 {
  property int i;
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve. -Steve

I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity. Andrei
Feb 07 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/13 4:55 PM, Jonathan M Davis wrote:
 On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis<jmdavisProg gmx.com>

 wrote:
 struct S
 {

  property int i;

 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve.

Except that mixins are generally unacceptable in APIs, because they don't end up in the documentation. That means that this works only if you don't care about documentation. So, it's almost useless. Putting property on there also looks better but isn't that big a deal. However, the lack of documentation _is_ a big deal.

Well there's the version(DDoc) ... etc. possibility. Andrei
Feb 07 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Thursday, 7 February 2013 at 20:26:10 UTC, Jonathan M Davis 
wrote:
 It works as long as you can limit the variable in some way. But 
 I believe that
 the main purpose in using public variables rather than actual 
 property
 functions when all they would do is get or set the variable is 
 to avoid lots
 of boilerplate code. It's incredibly common to get stuff like

 struct S
 {
  int i()  safe const pure nothrow
  { return _i; }

  int i(int value)  safe pure nothrow
  { return _i = value; }

  private int _i;
 }

 That's a lot of extra code whose only benefit is encapsulation. 
 So, it would be
 great if you could just do

 struct S
 {
  int i;
 }

 And with the ability to replace the variable with a property 
 function later if
 it ever needs to do more than just get or set makes it so that 
 encapsulation
 isn't a problem - except for the fact that there are certain 
 operations that
 you can do on a variable that you can't do on a property 
 function (e.g. taking
 its address or passing it by ref). Simply making it so that 
 doing

 struct S
 {
   property int i;
 }

 lowered into something like the first example would allow you 
 to avoid all of
 that boilerplate code and still have full encapsulation.

If it lowered into something like the first example would there really be any encapsulation? Wouldn't that be exactly the same as public int i? If this is the goal - to get rid of the boilerplate of accessors, it makes sense but a new feature is not necessary. If you want read/write access to a member but the benefit of being able to intercept access in the future start with struct S { int i; }. When the need arises to change the behavior, switch to: struct S { int i() safe const pure nothrow { // SPECIAL SAUCE return _i; } int i(int value) safe pure nothrow { // SPECIAL SAUCE return _i = value; } private int _i; } If you don't have any SPECIAL SAUCE then you don't need to switch. If you want more encapsulation and specifically don't want to provide write access, just read access then a mixin can do the trick of providing read access to s.i. In the future you can change the read accessor and provide one with SPECIAL SAUCE. struct S { mixin ReadOnly!_i; private int _i; }
 It's definitely true that you can never make a property 
 function completely
 emulate a variable, but all of the boilerplate required for 
 simple getters and
 setters is kind of ridiculous. I believe that avoiding that is 
 the primary
 reason that people want to be able to swap between variables 
 and property
 functions, and with a small addition to the language, we can 
 obviate that
 boilerplate.

No addition needed. Thanks Dan
Feb 07 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
 struct S
 {
   property int i;
 }


You missed the point. When this gets lowered to accessor functions and a private variable, you ensure that you can later on add your magic soup, without breaking code that relied on i being a real field. (E.g. taking the address, using +=, -=, ...) Although += or -= can still be added for properties, but the important thing is, that for an property declared field nothing is possible, that is not also possible with a property created by manually writing set/get methods.
Feb 07 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 struct S
 {
   property int i;
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve. -Steve
Feb 07 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Thursday, 7 February 2013 at 21:12:35 UTC, Steven 
Schveighoffer wrote:
 struct S
 {
    mixin(boilerplateProperty("i"));
 }

 I don't see this as a difficult problem to solve.

 -Steve

+1
Feb 07 2013
prev sibling next sibling parent "Geancarlo Rocha" <geancarlo.rocha gmail.com> writes:
In C#, they have introduced automatic properties for that purpose 
of "initial encapsulation":

public int i { get; set; } //get and set can be modified with 
private etc

Then the getter and setter methods are automatically implemented.


I'm not closely following the discussions involved in the 
re-design of properties, but I disagree with the people that 
believe properties are glorified fields. IMO, they are 
essentially functions, accessed like fields, that can set and/or 
expose state. I'm also against 2-parametrized properties btw.

Example: define a interface for geometric figures with a "area" 
property and then implement it for square, circle, hexagon, 
triangle etc

On Thursday, 7 February 2013 at 20:26:10 UTC, Jonathan M Davis 
wrote:
 It works as long as you can limit the variable in some way. But 
 I believe that
 the main purpose in using public variables rather than actual 
 property
 functions when all they would do is get or set the variable is 
 to avoid lots
 of boilerplate code. It's incredibly common to get stuff like

 struct S
 {
  int i()  safe const pure nothrow
  { return _i; }

  int i(int value)  safe pure nothrow
  { return _i = value; }

  private int _i;
 }

 That's a lot of extra code whose only benefit is encapsulation. 
 So, it would be
 great if you could just do

 struct S
 {
  int i;
 }

 And with the ability to replace the variable with a property 
 function later if
 it ever needs to do more than just get or set makes it so that 
 encapsulation
 isn't a problem - except for the fact that there are certain 
 operations that
 you can do on a variable that you can't do on a property 
 function (e.g. taking
 its address or passing it by ref). Simply making it so that 
 doing

 struct S
 {
   property int i;
 }

 lowered into something like the first example would allow you 
 to avoid all of
 that boilerplate code and still have full encapsulation.

 It's definitely true that you can never make a property 
 function completely
 emulate a variable, but all of the boilerplate required for 
 simple getters and
 setters is kind of ridiculous. I believe that avoiding that is 
 the primary
 reason that people want to be able to swap between variables 
 and property
 functions, and with a small addition to the language, we can 
 obviate that
 boilerplate.

 - Jonathan M Davis

Feb 07 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
 You missed the point. When this gets lowered to accessor 
 functions and a
 private variable, you ensure that you can later on add your 
 magic soup,
 without breaking code that relied on i being a real field. 
 (E.g. taking
 the address, using +=, -=, ...)

Quite likely I missed the point. Today I have: struct S { property int i; } Tomorrow I decide I need to track every time int i is read and written. How is that done? I assume that that sort of encapsulation is what we are after. Thanks Dan
Feb 07 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
I am not completely against this, but it feels quite artificial to make
a builtin feature complete this way. If we implement the property stuff
completely via library methods, I would like it more, but if it is
documented properly, might not be too bad:

struct S {
	mixin(property(int, "i"));
}

On Thu, 2013-02-07 at 16:12 -0500, Steven Schveighoffer wrote:
 struct S
 {
     mixin(boilerplateProperty("i"));
 }

Feb 07 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Feb 2013 17:25:16 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 struct S
 {
  property int i;
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve. -Steve

I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity.

My syntax highlighter highlights string and writeln, even though they aren't language builtins. If we establish a standard mixin template, certainly editors can be made to highlight such a mixin, along with providing the expected code completion. -Steve
Feb 07 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 February 2013 at 00:33:47 UTC, Steven Schveighoffer 
wrote:
 On Thu, 07 Feb 2013 17:25:16 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 struct S
 {
  property int i;
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve. -Steve

I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity.

My syntax highlighter highlights string and writeln, even though they aren't language builtins. If we establish a standard mixin template, certainly editors can be made to highlight such a mixin, along with providing the expected code completion.

Most does it when using the q string syntax.
Feb 07 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 7:39 PM, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

I salute the appeal to rigor and comprehensiveness. This is not a contest or a competition so I allowed myself to make this its own DIP: http://wiki.dlang.org/DIP24 Andrei
Feb 05 2013
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 6 February 2013 at 01:37:32 UTC, Andrei 
Alexandrescu wrote:
 This is not a contest or a competition so I allowed myself to 
 make this its own DIP: http://wiki.dlang.org/DIP24

Converted the old page into a redirect and added it to the index (Timon, I hope you don't mind). David
Feb 05 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 02:42 AM, David Nadlinger wrote:
 On Wednesday, 6 February 2013 at 01:37:32 UTC, Andrei Alexandrescu wrote:
 This is not a contest or a competition so I allowed myself to make
 this its own DIP: http://wiki.dlang.org/DIP24

Converted the old page into a redirect and added it to the index (Timon, I hope you don't mind). David

Perfect, thanks!
Feb 05 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 02:37 AM, Andrei Alexandrescu wrote:
 On 2/5/13 7:39 PM, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

I salute the appeal to rigor and comprehensiveness.

Thanks!
 This is not a contest or a competition so I allowed myself to make this
 its own DIP: http://wiki.dlang.org/DIP24

Makes sense. (As the two proposals agree on a meaning for most expressions I was not sure if that was enough for a full-blown DIP.)
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 20:34:11 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 02/06/2013 02:20 AM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr gmx.ch>  
 wrote:

 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

Has my vote. For what it's worth :)

Thanks! :) The full proposal or just the basic design part? (I think the full "semantic rewrite" idea may have some issues regarding excessive postblit/destruction, so I am not entirely sure if it is a good idea, but it was requested.)

All that I really care about is the specification of what property does. The semantic rewrite stuff is something I don't feel strongly either way. It would be nice, but at the same time, it doesn't feel necessary to me. One can always simply avoid it by not using the operators on properties.
 One thing that should be clarified, you should explicitly say "member
 function (static or instance)" instead of just member function.  The
 "optional this" kind of takes care of it, but you have to read it
 carefully to get that.  I think it should be more straightforward.

 -Steve

Done. Another thing that was not specified yet was what the compiler is supposed to do when it encounters overloads where some are property and some are not. (I have added "It is illegal to overload property-qualified functions against non- property-qualified functions.")

Sounds correct. I was reexamining the portion on the __traits rewrite. I think it is interesting how you have simply made property rewrite to __traits(propertyAccessors, x). There are a couple of clarifications I was curious about: 1. Does &prop work? If so, what does it do? 1a. if &prop doesn't work, does &__traits(propertyAccessors, prop) work (and give you the delegate to the property function overload set)? I can only imagine this is the reason you have the rewrite to a __traits call... 2. Inside the rules for when you do prop = exp, you specify that if the return is void, the expression is rewritten as (__traits(propertyAccessors, prop)(exp), prop). I see some issues with this: 2a. If you are NOT using the expression beyond the assignment, why call the accessor again? 2b. This would preclude write-only properties (as the second element of the comma expression is invalid). Is that intentional? 2c. What about ref returning properties? In those cases, the rewrite should be __traits(propertyAccessors, prop)() = exp; -Steve
Feb 05 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 00:39:55 UTC, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I 
 have prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short 
 sub-sections "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the 
 DIP23 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which 
 Andrei is preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear 
 how some case would be handled, feel free to ask.

I have to spend more time on the property part. For the optional () part, I want to raise concern about point 2 (the others make sense). In all other points, foo is either a call to function foo or the function foo itself. In point 2, we introduce a 3rd meaning of foo, identical to weird stuff we have in C/C++ (as we obviously aren't taking the address either of the function or of its result when executed). This object is an error of C and C++ we must get rid of. Point 1, 4 and 5 make sense. Point 3 is nonsensial if we want to really be rigorous as : returnType foo(TemplateArgs)(args) {} is equivalent to template foo(TemplateArgs) { returnType foo(args) {} } In this case foo is a template, not a function. foo!args is the function hen eponymous trick is used.
Feb 05 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 04:31 AM, deadalnix wrote:
 On Wednesday, 6 February 2013 at 00:39:55 UTC, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.

I have to spend more time on the property part. For the optional () part, I want to raise concern about point 2 (the others make sense). In all other points, foo is either a call to function foo or the function foo itself. In point 2, we introduce a 3rd meaning of foo, identical to weird stuff we have in C/C++ (as we obviously aren't taking the address either of the function or of its result when executed). This object is an error of C and C++ we must get rid of.

1. This would break a lot of code. 2. How to get a first-class function value (function pointer, delegate) from a function name otherwise?
 Point 1, 4 and 5 make sense.

 Point 3 is nonsensial if we want to really be rigorous as :
 returnType foo(TemplateArgs)(args) {}

 is equivalent to

 template foo(TemplateArgs) {
      returnType foo(args) {}
 }

 In this case foo is a template,

Yes, a function template. Note that functions overload against function templates.
 not a function. foo!args is the function
 hen eponymous trick is used.

I think you misunderstand. If we have eg: void foo(){ return 2; } void foo(int x)(){ return 2; } then we want: static assert(foo!2==2); Without rule 3, the code would be rewritten to static assert(foo()!2==2); And this would fail.
Feb 05 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-06 04:43, Timon Gehr wrote:

 Yes, a function template. Note that functions overload against function
 templates.

Maybe I'm misunderstanding something there but since when? Example: void foo () {} void foo (T) (T t) {} void main () {} Error: template main.foo(T)(T t) conflicts with function main.foo at... -- /Jacob Carlborg
Feb 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-06 09:07, deadalnix wrote:

 That is dmd's implementation, but not what the spec says.

I can't see that the spec says anything about this. It doesn't say it's legal neither illegal. -- /Jacob Carlborg
Feb 06 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 06, 2013 08:34:32 Jacob Carlborg wrote:
 On 2013-02-06 04:43, Timon Gehr wrote:
 Yes, a function template. Note that functions overload against function
 templates.

Maybe I'm misunderstanding something there but since when? Example: void foo () {} void foo (T) (T t) {} void main () {} Error: template main.foo(T)(T t) conflicts with function main.foo at...

They're _supposed_ to, but it's a long-standing bug that they don't, and AFAIK, it has yet to be fixed. - Jonathan M Davis
Feb 05 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 06:12 AM, deadalnix wrote:
 On Wednesday, 6 February 2013 at 03:43:28 UTC, Timon Gehr wrote:
 For the optional () part, I want to raise concern about point 2 (the
 others make sense).

 In all other points, foo is either a call to function foo or the
 function foo itself. In point 2, we introduce a 3rd meaning of foo,
 identical to weird stuff we have in C/C++ (as we obviously aren't taking
 the address either of the function or of its result when executed). This
 object is an error of C and C++ we must get rid of.

1. This would break a lot of code. 2. How to get a first-class function value (function pointer, delegate) from a function name otherwise?

2. I see no point in not making foo a first class function value. Not having it does complicate things for no benefit. Any complication should be properly motivated. This does not imply that optional () should be removed, as it is a mostly orthogonal problems (as scala shows).

So you would prefer Scala-like syntax? Scala uses suffix _ for what we use prefix &. Without something like that, type deduction is crippled.
 1. As of backward compat, & can be kept and follow the usual
 deprecation process.

I think this language change is not part of the DIP that fixes optional parens and property, but a separate improvement.
 ...
 Point 3 is nonsensial if we want to really be rigorous as :
 returnType foo(TemplateArgs)(args) {}

 is equivalent to

 template foo(TemplateArgs) {
     returnType foo(args) {}
 }

 In this case foo is a template,

Yes, a function template. Note that functions overload against function templates.
 not a function. foo!args is the function
 hen eponymous trick is used.

I think you misunderstand. If we have eg: void foo(){ return 2; } void foo(int x)(){ return 2; } then we want: static assert(foo!2==2); Without rule 3, the code would be rewritten to static assert(foo()!2==2); And this would fail.

Well the thing that a function CANNOT be used before template parameter (so function will be removed from overload set and only template will remains).

foo _is_ the overload set. In order to decide whether to rewrite it to foo() or not, it is necessary to look at the context ("before template parameter"), which is what rule 3 states. My example is still valid if you make the first overload templated. The rewrites must happen before overload resolution. In fact, they may decide which overload is ultimately chosen. (You can be certain that my working implementation of optional parens would cease to work if I removed rule 3.)
Feb 06 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 03:43:28 UTC, Timon Gehr wrote:
 For the optional () part, I want to raise concern about point 
 2 (the
 others make sense).

 In all other points, foo is either a call to function foo or 
 the
 function foo itself. In point 2, we introduce a 3rd meaning of 
 foo,
 identical to weird stuff we have in C/C++ (as we obviously 
 aren't taking
 the address either of the function or of its result when 
 executed). This
 object is an error of C and C++ we must get rid of.

1. This would break a lot of code. 2. How to get a first-class function value (function pointer, delegate) from a function name otherwise?

2. I see no point in not making foo a first class function value. Not having it does complicate things for no benefit. Any complication should be properly motivated. This does not imply that optional () should be removed, as it is a mostly orthogonal problems (as scala shows). 1. As of backward compat, & can be kept and follow the usual deprecation process.
 Point 1, 4 and 5 make sense.

 Point 3 is nonsensial if we want to really be rigorous as :
 returnType foo(TemplateArgs)(args) {}

 is equivalent to

 template foo(TemplateArgs) {
     returnType foo(args) {}
 }

 In this case foo is a template,

Yes, a function template. Note that functions overload against function templates.
 not a function. foo!args is the function
 hen eponymous trick is used.

I think you misunderstand. If we have eg: void foo(){ return 2; } void foo(int x)(){ return 2; } then we want: static assert(foo!2==2); Without rule 3, the code would be rewritten to static assert(foo()!2==2); And this would fail.

Well the thing that a function CANNOT be used before template parameter (so function will be removed from overload set and only template will remains).
Feb 05 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-06 01:39, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.


 (Also feel free to fix the formatting.)

+1 I would be nice with a couple of more examples. -- /Jacob Carlborg
Feb 05 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 07:34:33 UTC, Jacob Carlborg 
wrote:
 On 2013-02-06 04:43, Timon Gehr wrote:

 Yes, a function template. Note that functions overload against 
 function
 templates.

Maybe I'm misunderstanding something there but since when? Example: void foo () {} void foo (T) (T t) {} void main () {} Error: template main.foo(T)(T t) conflicts with function main.foo at...

That is dmd's implementation, but not what the spec says.
Feb 06 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 06, 2013 09:42:49 Jacob Carlborg wrote:
 On 2013-02-06 09:07, deadalnix wrote:
 That is dmd's implementation, but not what the spec says.

I can't see that the spec says anything about this. It doesn't say it's legal neither illegal.

I don't know what the spec says (I'd have to go digging through it), but TDPL is quite clear on the matter. And it's still in bugzilla as a bug: http://d.puremagic.com/issues/show_bug.cgi?id=1528 I really don't think that there's any question that it's supposed to work. It's just that the implementation hasn't been fixed yet. - Jonathan M Davis
Feb 06 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 7:39 PM, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.

So syntactic case (2) prescribes that when foo is in address-taken position "&foo", that means take its address as opposed to evaluate foo. That makes the use of "&" here sheer punctuation, as opposed to operator. There's also "(Note that redundant parentheses are assumed to be dropped in the parsing stage.)" It's unclear whether this makes &(foo) and &(((foo))) identical to &foo. If they don't, then "&" is not an operator in the expression "&foo" because an operator should be applicable to a parenthesized expression. If they do, in this context parens are also punctuation, not expression grouping; they don't enclose an expression, but instead define &(((...(foo)...))) as a sole syntactic unit (!). This also leads to potential confusion, seeing as &(foo) takes the address of foo, but &( true ? foo : bar ) does, in fact, take the address of whatever foo returns. This makes the role of "&", "(", and ")" in the proposal as both punctuation and operator painfully visible. This all makes DIP24 fail meet its own definition of success as far as I understand it, i.e. keeping "&" to mean operator and parens to mean grouping. In my opinion, it also makes DIP24 fail to improve over DIP23. DIP23 has in fact /fewer/ such problems, because it clarifies that &foo and &expr.foo are indivisible syntactic units; thus parentheses are not ascribed a special meaning by DIP23. On the contrary, as soon as parens are used, as in &(foo) or &( true ? foo : bar ), the usual meaning of parens enters in action and give the expression inside the usual meaning. I should point out that that's all okay, but we got to be clear about it. Tokens are used as both punctuation and operators all the time. For example, it may sound weird that (stuff) and ((stuff)) should ever mean distinct things, but writeln((1, 2)) does something different from writeln(1, 2). This is because the outer layer is punctuation and the inner layer is expression grouping. And nobody blinks an eye. The language just needs to be as clear as possible about which is which. If DIP25 gets approved, taking the address of ref results will be banned, and therefore that potential meaning of "&" disappears, which simplifies things. But we'll still have to live with the reality that in the constructs "&foo" and "&expr.foo", "&" is not an operator. And that's okay. Andrei
Feb 06 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 04:32 PM, Andrei Alexandrescu wrote:
 On 2/5/13 7:39 PM, Timon Gehr wrote:
 As my posts in the DIP23 thread have been left unanswered, I have
 prepared a counter proposal for DIP23 during the last hour.

 Everything DIP23 addresses is specified in the two short sub-sections
 "Optional parens" and " property: basic design".

 Those in favour of what was called "semantic rewrites" in the DIP23
 thread should probably read on further.

 All parts of this proposal are independent of DIP24 (which Andrei is
 preparing).

 http://wiki.dlang.org/DIP23_Counter_Proposal

 There are almost no examples yet, but in case it is not clear how some
 case would be handled, feel free to ask.

So syntactic case (2) prescribes that when foo is in address-taken position "&foo", that means take its address as opposed to evaluate foo. That makes the use of "&" here sheer punctuation, as opposed to operator.

Here and everywhere else. auto x = 5; auto y = &5; // error! auto z = &x; // ok!
 There's also "(Note that redundant parentheses are assumed to be dropped
 in the parsing stage.)" It's unclear whether this makes &(foo) and
 &(((foo))) identical to &foo. ...

That is exactly the case it describes. Yes it makes them identical.
 If they do, in this context parens are also
 punctuation, not expression grouping; they don't enclose an expression,
 but instead define &(((...(foo)...))) as a sole syntactic unit (!).

They are neither. They are just insignificant information thrown away by the parser.
 This also leads to potential confusion, seeing as &(foo) takes the
 address of foo, but &( true ? foo : bar ) does, in fact, take the
 address of whatever foo returns.

Ah, very good point! But please note that this is 100% a ternary operator issue. Interestingly, what you describe is how it actually works in Scala. I do not feel strongly about this, but we might as well do it the other way. I have clarified what it means to occur in a context. I think the ternary expression is the only composite expression that can occur in lvalue position that behaves this way. This change also 'fixes' the related case (true ? foo : bar)().
 This makes the role of "&", "(", and
 ")" in the proposal as both punctuation and operator painfully visible.

The syntax tree looks like this: & | ? / | \ / | \ true foo bar There are no "(" ")". Why would they affect semantics?
 This all makes DIP24 fail meet its own definition of success as far as I
 understand it, i.e. keeping "&" to mean operator and parens to mean
 grouping.

1. There is no point where the DIP calls "&" an "operator". 2. It succeeds in keeping parens mean grouping. (Given any of the two behaviours of ternary expressions.) DIP24 meets its own definition of success.
 In my opinion, it also makes DIP24 fail to improve over DIP23.
 ...

In my opinion too. It conveniently also makes all other statements true, as the line of reasoning crucially depends on fallaciously ascribing properties of the ternary operator to the parens enclosing it. (The second fallacy is ascribing the properties of rvalue vs. lvalue distinction inherited from C to DIP24.)
 DIP23 has in fact /fewer/ such problems, because it clarifies that &foo
 and &expr.foo are indivisible syntactic units; thus parentheses are not
 ascribed a special meaning by DIP23.

That is inaccurate, and it is special enough that I do not care to fully formalize the special meaning ascribed to parentheses by DIP23. Basically it makes use of parens affect whether some position in the syntax tree is treated as lvalue or rvalue position in some special cases.
 On the contrary, as soon as parens
 are used, as in &(foo) or &( true ? foo : bar ), the usual meaning
 of parens enters in action and give the expression inside the usual meaning.

You mean the usual rvalue position meaning, eliminating the lvalue position meaning, even if the expression actually occurs in an lvalue position. That is unusual.
 I should point out that that's all okay, but we got to be clear about
 it. Tokens are used as both punctuation and operators all the time. For
 example, it may sound weird that (stuff) and ((stuff)) should ever mean
 distinct things,

They never do and never should.
 but writeln((1, 2)) does something different from
 writeln(1, 2).

I guess this attempts to instantiate 'stuff' with "1, 2"? The substring "((1, 2))" in the first example does not correspond to a node in the syntax tree. What is the point?
 This is because the outer layer is punctuation and the
 inner layer is expression grouping.

One of the usages is unary and the other is binary. Another example of this is ~x and x~y. This also shows that the two usages do not have to be related in any way, so nothing is weird.
 And nobody blinks an eye.

Of course they do. This situation is one cause of the extensive built-in tuple discussions.
 The language just needs to be as clear as possible about which is which.

 If DIP25 gets approved, taking the address of ref results will be
 banned, and therefore that potential meaning of "&" disappears, which
 simplifies things.

How? It only adds code to my front-end to make sure the case is actually caught and properly reported. It does not even simplify the byte code compiler. (Because it uses similar code paths for the &foo() and foo()=exp cases.)
 But we'll still have to live with the reality that in
 the constructs "&foo" and "&expr.foo", "&" is not an operator.

As well as in all other constructs where it is used in unary form.
 And that's okay.

Except for the unfortunate confusion it can cause.
Feb 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/6/13 12:41 PM, Timon Gehr wrote:
 If they do, in this context parens are also
 punctuation, not expression grouping; they don't enclose an expression,
 but instead define &(((...(foo)...))) as a sole syntactic unit (!).

They are neither. They are just insignificant information thrown away by the parser.

Nononono. Hold them horses. We can't gloss over things like that. That means in this context parens don't have the usual meaning of expression grouping, because what's inside is not an expression. They are punctuation that makes &((...(symbol)...)) one syntactic unit identical to &symbol.
 This also leads to potential confusion, seeing as &(foo) takes the
 address of foo, but &( true ? foo : bar ) does, in fact, take the
 address of whatever foo returns.

Ah, very good point! But please note that this is 100% a ternary operator issue.

Not at all. What do these mean? &({ return fun; }()) &(fun, fun) The last one is really fun because the same thing may be evaluated first and then have its address taken. Wow. But of course it doesn't. Why? Because "&" and parens have special meaning for &(fun), which is my point.
 This all makes DIP24 fail meet its own definition of success as far as I
 understand it, i.e. keeping "&" to mean operator and parens to mean
 grouping.

1. There is no point where the DIP calls "&" an "operator".

It doesn't have to. It's everywhere else in the language. That's my point: new meaning of "&".
 2. It succeeds in keeping parens mean grouping. (Given any of the two
 behaviours of ternary expressions.)

 DIP24 meets its own definition of success.

Of course, if moving the goalposts is an option. My understanding was that the express purpose of DIP24 was to avoid potential confusion and avoid ascribing new meaning to "&" or parens. As far as I can tell it failed at both: "&" is sometimes not an operator, and parens sometimes don't encompass expressions.
 In my opinion, it also makes DIP24 fail to improve over DIP23.
 ...

In my opinion too. It conveniently also makes all other statements true, as the line of reasoning crucially depends on fallaciously ascribing properties of the ternary operator to the parens enclosing it.

That got destroyed above.
 (The second fallacy is ascribing the properties of rvalue vs. lvalue
 distinction inherited from C to DIP24.)

 DIP23 has in fact /fewer/ such problems, because it clarifies that &foo
 and &expr.foo are indivisible syntactic units; thus parentheses are not
 ascribed a special meaning by DIP23.

That is inaccurate, and it is special enough that I do not care to fully formalize the special meaning ascribed to parentheses by DIP23.

DIP23 does not ascribe any special meaning to parentheses. That's actually part of the point and a good thing about it. I think there's a misunderstanding somewhere.
 Basically it makes use of parens affect whether some position in the
 syntax tree is treated as lvalue or rvalue position in some special cases.

No, that is incorrect.
 If DIP25 gets approved, taking the address of ref results will be
 banned, and therefore that potential meaning of "&" disappears, which
 simplifies things.

How? It only adds code to my front-end to make sure the case is actually caught and properly reported. It does not even simplify the byte code compiler. (Because it uses similar code paths for the &foo() and foo()=exp cases.)

I think DIP24 means more code to the front end, more special rules, more explaining, and more confusion than DIP23.
 But we'll still have to live with the reality that in
 the constructs "&foo" and "&expr.foo", "&" is not an operator.

As well as in all other constructs where it is used in unary form.
 And that's okay.

Except for the unfortunate confusion it can cause.

And that DIP24 does not get rid of. Andrei
Feb 06 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/06/2013 08:09 PM, Andrei Alexandrescu wrote:
 On 2/6/13 12:41 PM, Timon Gehr wrote:
 If they do, in this context parens are also
 punctuation, not expression grouping; they don't enclose an expression,
 but instead define &(((...(foo)...))) as a sole syntactic unit (!).

They are neither. They are just insignificant information thrown away by the parser.

Nononono. Hold them horses. We can't gloss over things like that.

We don't! What I have stated is accurate. (You can check the DMD source, if that helps.)
 That means in this context parens don't have the usual meaning of expression
 grouping, because what's inside is not an expression.

PrimaryExpression: Identifier ...
 They are punctuation that makes &((...(symbol)...)) one syntactic unit
identical
 to &symbol.

Again, &((...(symbol)...)) and &symbol are both serialized representations of & | symbol I.e. they mean the same thing.
 This also leads to potential confusion, seeing as &(foo) takes the
 address of foo, but &( true ? foo : bar ) does, in fact, take the
 address of whatever foo returns.

Ah, very good point! But please note that this is 100% a ternary operator issue.

Not at all.

I meant 'as opposed to a paren issue'. &( true ? foo : bar ) // <-- note the ternary operator
 What do these mean?

 &({ return fun; }())

That is equivalent to &(&__dgliteral0)() where auto __dgliteral0(){ return fun; }
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.
 The last one is really fun because the same thing may be evaluated first
 and then have its address taken. Wow. But of course it doesn't. Why?
 Because "&" and parens have special meaning for &(fun), which is my point.

Now you are saying that parens _do_ have a special meaning?
 This all makes DIP24 fail meet its own definition of success as far as I
 understand it, i.e. keeping "&" to mean operator and parens to mean
 grouping.

1. There is no point where the DIP calls "&" an "operator".

It doesn't have to. It's everywhere else in the language.

No way. I repeat: auto x = 5; auto y = &5; // error! auto z = &x; // ok!
 That's my point: new meaning of "&".
...

Obviously your reading of my post was quite shallow.
 2. It succeeds in keeping parens mean grouping. (Given any of the two
 behaviours of ternary expressions.)

 DIP24 meets its own definition of success.

Of course, if moving the goalposts is an option.

It is. DIP24 is in draft stage. Moving the goalposts was not necessary so far though.
 My understanding was that the express purpose of DIP24 was to avoid potential
confusion and avoid ascribing new meaning to "&" or parens.
 As far as I can tell it failed at both: "&" is sometimes not an operator, and
parens sometimes don't encompass expressions.

"&" is never an operator and parens always encompass expressions. Additionally, there is a bunch of rewrite rules to get parentheses on function calls optional.
 In my opinion, it also makes DIP24 fail to improve over DIP23.
 ...

In my opinion too. It conveniently also makes all other statements true, as the line of reasoning crucially depends on fallaciously ascribing properties of the ternary operator to the parens enclosing it.

That got destroyed above.

No. It's just that both ternary expressions and comma expressions can propagate lvalue-positions, and I had forgotten about the comma expression as I was in a hurry.
 (The second fallacy is ascribing the properties of rvalue vs. lvalue
 distinction inherited from C to DIP24.)

 DIP23 has in fact /fewer/ such problems, because it clarifies that &foo
 and &expr.foo are indivisible syntactic units; thus parentheses are not
 ascribed a special meaning by DIP23.

That is inaccurate, and it is special enough that I do not care to fully formalize the special meaning ascribed to parentheses by DIP23.

DIP23 does not ascribe any special meaning to parentheses.

It does. To the point that the parser has to be changed, just in order to implement rewrite rules.
 That's actually part of the point and a good thing about it.
 I think there's a misunderstanding somewhere.

Definitely.
 Basically it makes use of parens affect whether some position in the
 syntax tree is treated as lvalue or rvalue position in some special cases.

No, that is incorrect.

It is correct. &fun // <-- fun occurs in lvalue position &(fun) // <-- (fun) occurs in lvalue position You are now arguing for making the 'fun''s in "fun" and "(fun)" behave differently. The first should behave as if it was in address-taken (lvalue) position and the second should behave as if it was not (as if it was in rvalue position). The rules for context dependency were intended to closely parallel those of lvalue position propagation in order to minimize the amount of new rules. If you see any other differences, please step up.
 If DIP25 gets approved, taking the address of ref results will be
 banned, and therefore that potential meaning of "&" disappears, which
 simplifies things.

How? It only adds code to my front-end to make sure the case is actually caught and properly reported. It does not even simplify the byte code compiler. (Because it uses similar code paths for the &foo() and foo()=exp cases.)

I think DIP24 means more code to the front end, more special rules,

Well, you are wrong, and as far as I can tell, the speculation is entirely unfounded. DIP23 is not even _implementable_ currently, because it does not even attempt to handle all cases that are necessary to handle. In order to do that, it would need to copy most of the rules of DIP24. Then, making &fun and &(fun) behave differently is more work than making them behave the same.
 more explaining,  and more confusion than DIP23.

I do not have any hard data on this, but &fun and &(fun) meaning different things is extremely confusing. Note that this is not actually part of DIP23 yet for non- property functions. (It is just left unspecified.) I guess this is an oversight?
 But we'll still have to live with the reality that in
 the constructs "&foo" and "&expr.foo", "&" is not an operator.

As well as in all other constructs where it is used in unary form.


Still holds.
 And that's okay.

Except for the unfortunate confusion it can cause.

And that DIP24 does not get rid of.

Neither does DIP23. That is not their purpose.
Feb 06 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/07/2013 02:56 PM, Steven Schveighoffer wrote:
 On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix <deadalnix gmail.com> wrote:

 On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.

Adding more special cases are not gonna create a good DIP.

I don't they are so much a special case, as they are a clarification. The two "exceptions" are simply explaining that because ternary operator and comma operators evaluate to an lvalue, it is equivalent to putting the & on the resulting lvalue. -Steve

Exactly. Those operators already have this behaviour in other contexts. OT: One of my favourite comma/ternary-isms is the following: import std.typecons : tuple; void foo(int x){} void main(){ int x; foo((x++,tuple.expand),x,(x++,tuple.expand)); foo(true?tuple.expand:tuple.expand,x,); } I think it is valid code. :-) DMD cannot handle it though.
Feb 07 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/08/2013 05:22 AM, deadalnix wrote:
 ...

 You have the following behavior :
   - & take the address of what is before.
   - foo is call to function foo.
   - special case : &foo

foo(); foo!() tmpl!foo alias sym=foo;
 is the first class function foo. (here expression foo have a new meaning).

Again, & behaves like that even for variables. auto x = 5; auto y = &5; // error auto z = &x; // ergo: this 'x' is different assert(x==5); // from this one
   - In a comma expression, if the last item is a function, it is
 evaluated, unless the comma expression is in an address of context, in
 which case the function pointer is returned.
   - Same goes for ternary, except that both branches are evaluated in
 that context.

 This is exactly how special case (3) turtle down to definition of many
 other languages constructs.

I think ternary and comma is a comprehensible list of the many other language constructs.
 For instance,

 int a;
 int foo() { return a }

 static assert(is(typeof(foo) == typeof(a))); // Pass
 condition ? foo : a; // OK.
 &(condition ? foo : a); // Type error between foo of unexpressible type
 (static array of instructions)

(This does not make any sense. Instructions are often variable-size.)
 and a of type int.

The error message is a QOI issue. This is what DMD reports if foo is a double, and a is an int: Error: cast(double)a is not an lvalue Error: cannot implicitly convert expression (condition ? & foo : (__error)) of type double* to double* (Another point: As you may have noticed, the constructs &(a?b:c) and &(a,b) are "special cased" _anyway_.) IMHO this is roughly what should be reported in both the case that foo is a function and that foo is a double, maybe giving away a little more information: error: cannot take address of expression '(condition ? foo : a)' &(condition ? foo : a); ^~~~~~~~~~~~~~~~~~~~~~ I think DIP24 is a valid way to go. The simplest alternative design I'd be fine with would be to remove property, mandate parens on non-ufcs calls, identify function names with their function pointers/delegates, disallow foo = functionArgument and &foo for foo a function or method, and call it a day. (This would not simplify lvalue/rvalue rules, but reduce the number of cases where they apply.)
Feb 08 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 15:32:33 UTC, Andrei 
Alexandrescu wrote:
 So syntactic case (2) prescribes that when foo is in 
 address-taken position "&foo", that means take its address as 
 opposed to evaluate foo. That makes the use of "&" here sheer 
 punctuation, as opposed to operator.

That is one of the node of the optional () problem. Your DIP have similar issue with &.
 This also leads to potential confusion, seeing as &(foo) takes 
 the address of foo, but &( true ? foo : bar ) does, in fact, 
 take the address of whatever foo returns. This makes the role 
 of "&", "(", and ")" in the proposal as both punctuation and 
 operator painfully visible.

As ell, your proposal have similar issues.
 This all makes DIP24 fail meet its own definition of success as 
 far as I understand it, i.e. keeping "&" to mean operator and 
 parens to mean grouping. In my opinion, it also makes DIP24 
 fail to improve over DIP23.

 DIP23 has in fact /fewer/ such problems, because it clarifies 
 that &foo and &expr.foo are indivisible syntactic units; thus 
 parentheses are not ascribed a special meaning by DIP23. On the 
 contrary, as soon as parens are used, as in &(foo) or &( true ? 
 foo : bar ), the usual meaning of parens enters in action and 
 give the expression inside the usual meaning.

I do see special meaning as an issue, as it complexity the language. DIP24 is an improvement in that regard over DIP23.
 If DIP25 gets approved, taking the address of ref results will 
 be banned, and therefore that potential meaning of "&" 
 disappears, which simplifies things. But we'll still have to 
 live with the reality that in the constructs "&foo" and 
 "&expr.foo", "&" is not an operator. And that's okay.

That is cascading the problem, not solving it.
Feb 06 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.

Adding more special cases are not gonna create a good DIP. Can't we make foo evaluate the the first class function object ? And then figure out if/when it is safe to auto evaluate first class functions ? It seems to me like the only direction that do not ends up in an explosion of special cases.
Feb 06 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix <deadalnix gmail.com> wrote:

 On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.

Adding more special cases are not gonna create a good DIP.

I don't they are so much a special case, as they are a clarification. The two "exceptions" are simply explaining that because ternary operator and comma operators evaluate to an lvalue, it is equivalent to putting the & on the resulting lvalue. -Steve
Feb 07 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 06 Feb 2013 16:30:09 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 I do not have any hard data on this, but &fun and &(fun) meaning  
 different things is extremely confusing.

I can vouch that I find it confusing. At least on one other occasion, Walter nixed a feature because of this. It was for const(X) to mean tail-const and const X to mean full const. The point was made that const(X) and const X should be equivalent, and to do otherwise will result in tremendous confusion. I see a similar pattern here. -Steve
Feb 07 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 7 February 2013 at 13:56:17 UTC, Steven 
Schveighoffer wrote:
 On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix 
 <deadalnix gmail.com> wrote:

 On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr 
 wrote:
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.

Adding more special cases are not gonna create a good DIP.

I don't they are so much a special case, as they are a clarification. The two "exceptions" are simply explaining that because ternary operator and comma operators evaluate to an lvalue, it is equivalent to putting the & on the resulting lvalue.

You have the following behavior : - & take the address of what is before. - foo is call to function foo. - special case : &foo is the first class function foo. (here expression foo have a new meaning). - In a comma expression, if the last item is a function, it is evaluated, unless the comma expression is in an address of context, in which case the function pointer is returned. - Same goes for ternary, except that both branches are evaluated in that context. This is exactly how special case (3) turtle down to definition of many other languages constructs. For instance, int a; int foo() { return a } static assert(is(typeof(foo) == typeof(a))); // Pass condition ? foo : a; // OK. &(condition ? foo : a); // Type error between foo of unexpressible type (static array of instructions) and a of type int.
Feb 07 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Feb 2013 23:22:45 -0500, deadalnix <deadalnix gmail.com> wrote:

 On Thursday, 7 February 2013 at 13:56:17 UTC, Steven Schveighoffer wrote:
 On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix <deadalnix gmail.com>  
 wrote:

 On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
 &(fun, fun)

Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.

Adding more special cases are not gonna create a good DIP.

I don't they are so much a special case, as they are a clarification. The two "exceptions" are simply explaining that because ternary operator and comma operators evaluate to an lvalue, it is equivalent to putting the & on the resulting lvalue.

You have the following behavior : - & take the address of what is before. - foo is call to function foo. - special case : &foo is the first class function foo. (here expression foo have a new meaning). - In a comma expression, if the last item is a function, it is evaluated, unless the comma expression is in an address of context, in which case the function pointer is returned.

I think it's consistent, and no special cases. foo is treated as a fucntion name, until it is evaluated without any adornments, in which case it becomes a function call, or when the address operator is applied to it. In other words: &(foo, foo); => foo(); &(foo); => foo(); &foo; (foo, foo); => foo(); foo; => foo(); foo(); Let's note here that by opting on the side of NOT adding optional parens by default, both cases are possible: &(foo, foo()); and &(foo, foo); Under DIP23 (and the current implementation), both are equivalent, and expressive power is less.
   - Same goes for ternary, except that both branches are evaluated in  
 that context.

I would see the expression the same way, foo's meaning is not evaluated until the ternary expression is resolved. For example: condition ? foo : foo; => foo; => foo(); &(condition ? foo : foo) => &(foo); => &foo;
 This is exactly how special case (3) turtle down to definition of many  
 other languages constructs. For instance,

 int a;
 int foo() { return a }

 static assert(is(typeof(foo) == typeof(a))); // Pass

I'm unsure whether this should pass or fail. It seems disingenuous to make typeof(foo) equivalent to typeof(foo()), since foo is NOT an integer. If we err on the side of expressiveness, typeof(foo) should be the function type, not an int.
 condition ? foo : a; // OK.

I would say not ok. you have to do: condition ? foo() : a;
 &(condition ? foo : a); // Type error between foo of unexpressible type

Same, also not ok. This all seems consistent to me. It is more consistent than either the current dmd implementation, or the proposed DIP23. I can see however, that no matter what, there is going to be confusion. The simple rule is that optional parentheses only apply after all other reductions do not consider the function name as a function. The meaning of foo could be explicitly considered as a function call by including the parentheses. -Steve
Feb 08 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan <chadjoan gmail.com> wrote:

 On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
 ...

 The semantic rewrite stuff is something I don't feel strongly either
 way. It would be nice, but at the same time, it doesn't feel necessary
 to me. One can always simply avoid it by not using the operators on
 properties.

A core feature of properties is that variables can be migrated to them (and back) without breaking any of the caller's code. Forbidding more than half of D's operators on them will definitely break this attribute.

I find this explanation lacking. A field supports operations that are impossible to implement with properties, there will never be a non-code-breaking change from a field to a property. So it's a matter of "how much" breakage you want to allow. This is really a judgment call, there is no "right" answer. The closest you can get to a field is to ref an actual field. But in that case, I don't see the point of the property, since you give unfettered access to the field! The whole point of having properties that I see is to implement things you CAN'T implement with a field, or are more cumbersome. Like read-only fields. Such a change would necessarily and on purpose break code. -Steve
Feb 07 2013
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 07 Feb 2013 15:02:41 -0000, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan <chadjoan gmail.com> wrote:

 On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
 ...

 The semantic rewrite stuff is something I don't feel strongly either
 way. It would be nice, but at the same time, it doesn't feel necessary
 to me. One can always simply avoid it by not using the operators on
 properties.

A core feature of properties is that variables can be migrated to them (and back) without breaking any of the caller's code. Forbidding more than half of D's operators on them will definitely break this attribute.

I find this explanation lacking. A field supports operations that are impossible to implement with properties, there will never be a non-code-breaking change from a field to a property. So it's a matter of "how much" breakage you want to allow. This is really a judgment call, there is no "right" answer. The closest you can get to a field is to ref an actual field. But in that case, I don't see the point of the property, since you give unfettered access to the field! The whole point of having properties that I see is to implement things you CAN'T implement with a field, or are more cumbersome. Like read-only fields. Such a change would necessarily and on purpose break code.

There are several "points" to properties it would seem: http://en.wikipedia.org/wiki/Property_(programming) I have heard the goal Chad mentions said numerous times in similar discussions (to allow migration of fields to properties and back without breaking caller code) and I imagine this would be true and work in all cases for languages which don't have pointers, perhaps. But as D has pointers there can and probably does exist caller code which takes the address of a public field and would therefore simply break if that field was changed into a "property" (AKA method call). Now, perhaps there is some magic the compiler could do to make it work again, but if to achieve this we really have to jump through some crazy hoops or add complexity and edge-cases to the language then it's just not worth it, IMO. And, as Steven has said implementing read-only fields and adding layers of functionality are 2 other goals/points of properties and these are certainly useful by themselves, with or without any other benefits. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Feb 07 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 struct S
 {
 
  property int i;
 
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve.

Except that mixins are generally unacceptable in APIs, because they don't end up in the documentation. That means that this works only if you don't care about documentation. So, it's almost useless. Putting property on there also looks better but isn't that big a deal. However, the lack of documentation _is_ a big deal. - Jonathan M Davis
Feb 07 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
That is actually a good point.

On Thu, 2013-02-07 at 22:55 +0100, Jonathan M Davis wrote:
 Except that mixins are generally unacceptable in APIs, because they
 don't end 
 up in the documentation. That means that this works only if you don't
 care 
 about documentation. So, it's almost useless. Putting  property on
 there also 
 looks better but isn't that big a deal. However, the lack of
 documentation 
 _is_ a big deal.

Feb 07 2013
prev sibling next sibling parent "Dan" <dbdavidson yahoo.com> writes:
On Thursday, 7 February 2013 at 21:55:12 UTC, Jonathan M Davis 
wrote:
 Except that mixins are generally unacceptable in APIs, because 
 they don't end
 up in the documentation. That means that this works only if you 
 don't care
 about documentation. So, it's almost useless. Putting  property 
 on there also
 looks better but isn't that big a deal. However, the lack of 
 documentation
 _is_ a big deal.

Again, why would you need to property for the case of a read/write pattern. Just make it public: struct S { // Best int ever int i; }, then switch to this as needed: struct S { < accessors > // Best int ever int _i; } when needed. This way you have documentation still in tact. If you want read accessor only from the start, go with: struct S { mixin ReadOnly!_i; // Best int ever int _i; } I can understand documenting a member - quite important. But documentation on a generated accessor is not necessary. And if you customize it you can document it. No extra feature needed. Thanks Dan
Feb 07 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Feb 2013 16:55:01 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:
 struct S
 {

  property int i;

 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve.

Except that mixins are generally unacceptable in APIs, because they don't end up in the documentation. That means that this works only if you don't care about documentation. So, it's almost useless. Putting property on there also looks better but isn't that big a deal. However, the lack of documentation _is_ a big deal.

True. But we can fix that just as easily (will ddoc currently parse mixin-generated docs? If not it should). -Steve
Feb 07 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 07, 2013 22:19:53 Dan wrote:
 On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
 You missed the point. When this gets lowered to accessor
 functions and a
 private variable, you ensure that you can later on add your
 magic soup,
 without breaking code that relied on i being a real field.
 (E.g. taking
 the address, using +=, -=, ...)

Quite likely I missed the point. Today I have: struct S { property int i; } Tomorrow I decide I need to track every time int i is read and written. How is that done? I assume that that sort of encapsulation is what we are after.

You rewrite it as explicit property functions. No code breaks, because it was really property functions all along. You just didn't have to type them. - Jonathan M Davis
Feb 07 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 February 2013 at 04:06:40 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 07, 2013 22:19:53 Dan wrote:
 On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
 You missed the point. When this gets lowered to accessor
 functions and a
 private variable, you ensure that you can later on add your
 magic soup,
 without breaking code that relied on i being a real field.
 (E.g. taking
 the address, using +=, -=, ...)

Quite likely I missed the point. Today I have: struct S { property int i; } Tomorrow I decide I need to track every time int i is read and written. How is that done? I assume that that sort of encapsulation is what we are after.

You rewrite it as explicit property functions. No code breaks, because it was really property functions all along. You just didn't have to type them.

That seems to me like one of the best proposed idea in many thread happening on the subject.
Feb 07 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 07, 2013 23:15:14 Dan wrote:
 On Thursday, 7 February 2013 at 21:55:12 UTC, Jonathan M Davis
 
 wrote:
 Except that mixins are generally unacceptable in APIs, because
 they don't end
 up in the documentation. That means that this works only if you
 don't care
 about documentation. So, it's almost useless. Putting  property
 on there also
 looks better but isn't that big a deal. However, the lack of
 documentation
 _is_ a big deal.

Again, why would you need to property for the case of a read/write pattern. Just make it public: struct S { // Best int ever int i; },

But if you do that, then code that uses S can do stuff like take the address of i or pass it by ref. That code will then break when you turn it into property functions later. That's unacceptable, meaning that in almost all cases, people just create getters and setters which do almost nothing. It's boilerplate that we shouldn't need. - Jonathan M Davis
Feb 07 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 07, 2013 17:34:19 Andrei Alexandrescu wrote:
 On 2/7/13 4:55 PM, Jonathan M Davis wrote:
 On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
 On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis<jmdavisProg gmx.com>
 
 wrote:
 struct S
 {
 
  property int i;
 
 }

struct S { mixin(boilerplateProperty("i")); } I don't see this as a difficult problem to solve.

Except that mixins are generally unacceptable in APIs, because they don't end up in the documentation. That means that this works only if you don't care about documentation. So, it's almost useless. Putting property on there also looks better but isn't that big a deal. However, the lack of documentation _is_ a big deal.

Well there's the version(DDoc) ... etc. possibility.

Except then you're being forced to throw in a different sort of boilerplate code. version(D_Ddoc) { /// DDoc for prop int prop; } else { mixin(boilerplateProperty!int("prop")); } is enough extra that it's arguably worse than just declaring the property functions. If you could do /// DDoc for prop mixin(boilerplateProperty!int("prop")); then that would be okay (though it would be uglier than just putting property on it to do the same thing). But we can't do that, not and have it show up in the documentation. - Jonathan M Davis
Feb 07 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 8 February 2013 at 05:49:39 UTC, Jonathan M Davis 
wrote:
 On Thursday, February 07, 2013 23:15:14 Dan wrote:
 On Thursday, 7 February 2013 at 21:55:12 UTC, Jonathan M Davis 
 wrote:
 Except that mixins are generally unacceptable in APIs, 
 because they don't end up in the documentation. That means 
 that this works only if you don't care about documentation. 
 So, it's almost useless. Putting  property on there also 
 looks better but isn't that big a deal. However, the lack of 
 documentation _is_ a big deal.

Again, why would you need to property for the case of a read/write pattern. Just make it public: struct S { // Best int ever int i; },

But if you do that, then code that uses S can do stuff like take the address of I or pass it by ref. That code will then break when you turn it into property functions later. That's unacceptable, meaning that in almost all cases, people just create getters and setters which do almost nothing. It's boilerplate that we shouldn't need.

I hope I'm not missing the point; But I see a big dilemma about the whole ref/not ref(anymore) issue. Then I begin thinking: If you don't Mark it as part of the public API, why should it matter? Unless it's just a storage for data (which you guarantee to be ref), or publicly noted for DDoc, then making use of a internal implementation is wrong (even if it isn't marked private). It may be similar to... struct S { int i; auto front() {return i;} /// enum empty = false; /// void popFront() {i++;} /// } //original void func(S input) { writeln(input.i); input.i++; } //turned into referring to a range void func(R)(R input) if (isRange!(R)) { //Initially built/tested with struct S and works //but forgot to update. Still works in his own code writeln(input.i); input.i++; } If on the other hand if 'i' was intended part of the API, you can rely on it being ref-able unless there's a major change in design. struct S { int i; /// iterator number, part of API ref auto front() {return i;} /// ... } Also if the programmer's code gets broke they can always avoid upgrading until later, and fix their code when they are ready for it. Most fixes will be minor (even if they show up dozens of times).
Feb 08 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 08, 2013 22:38:35 Era Scarecrow wrote:
 If on the other hand if 'i' was intended part of the API, you
 can rely on it being ref-able unless there's a major change in
 design.
 
 struct S {
 int i; /// iterator number, part of API
 ref auto front() {return i;} ///
 ...
 }

The idea is that it's supposed to be part of the public API and that you're supposed to be able to add code to it later which does additional checking or completely changes how its implemented internally. This is trivial to do with functions, because they provide proper encapsulation. You can change the implementation as much as you like without breaking the API. But many getter and setter functions just get and set a variable without doing anything else making them useless boilerplate beyond the fact that they provide encapsulation. So, what property functions are trying to do is allow you to declare it as a public variable first (avoiding the boilerplate) and then only turn into property functions (with the variable being private) if you need the getter or setter to do something extra or different later. The one hitch in that is the fact that there a few things that you can do with a public variable that you can't do with a property function - things that you _don't_ want anyone doing with the public variable (like taking its address or passing it by ref). So, lacking a way to mark a public variable as a property, choosing to start with a public variable makes it likely that you're going to break code when the variable is converted to a pair property functions later. On the other hand, if you can mark the variable as a property (in which case the compiler either makes it illegal to do anything with that variable that you couldn't do with property functions, or it just lowers the variable to a pair property functions, and the variable isn't actually public anymore), then you can avoid breaking code. But the idea is to do this in a way that's transparent to users of the struct or class. They shouldn't care how a property is implemented. We want the encapsulation even when it's declared as a public variable (because we're really just looking to avoid boilerplate code). What I'm describing here is how properties are typically presented in C#, and it's what a lot of us would like to be able to do with D. - Jonathan M Davis
Feb 08 2013