www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - While we're lynching features, how bout' them omittable parens?

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Nevermind properties.  Any chance we can forbid the omittable
parentheses, at least in the lhs of an assignment expression?

In the more general case, any value type that gets modified but never
read or copied elsewhere is probably either dead code, a bug, or a
benchmark.  The latter is easy to fix by adding the necessary read/copy
(return the value, pass it to a global or function, etc).  It'd be great
if this kind of thing were a compile time error.

Code like this shouldn't compile:

struct S { int a = 0; }
S foo() { S s; return s; }

void main()
{
    foo.a++;
}
May 18 2009
next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?

 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/copy
 (return the value, pass it to a global or function, etc).  It'd be great
 if this kind of thing were a compile time error.

 Code like this shouldn't compile:

 struct S { int a = 0; }
 S foo() { S s; return s; }

 void main()
 {
    foo.a++;
 }
This is not because of the omittable parens. Even with added parens that code should not compile! L.
May 18 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Lionello Lunesu wrote:
 
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?

 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/copy
 (return the value, pass it to a global or function, etc).  It'd be great
 if this kind of thing were a compile time error.

 Code like this shouldn't compile:

 struct S { int a = 0; }
 S foo() { S s; return s; }

 void main()
 {
    foo.a++;
 }
This is not because of the omittable parens. Even with added parens that code should not compile! L.
Agreed!
May 18 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s article
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?

 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/copy
 (return the value, pass it to a global or function, etc).  It'd be great
 if this kind of thing were a compile time error.

 Code like this shouldn't compile:

 struct S { int a = 0; }
 S foo() { S s; return s; }

 void main()
 {
    foo.a++;
 }
This is not because of the omittable parens. Even with added parens that code should not compile! L.
Agreed!
Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
May 18 2009
next sibling parent BCS <none anon.com> writes:
Hello dsimcha,

 == Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s article
 
 Lionello Lunesu wrote:
 
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
 
 In the more general case, any value type that gets modified but
 never read or copied elsewhere is probably either dead code, a bug,
 or a benchmark.  The latter is easy to fix by adding the necessary
 read/copy (return the value, pass it to a global or function, etc).
 It'd be great if this kind of thing were a compile time error.
 
 Code like this shouldn't compile:
 
 struct S { int a = 0; }
 S foo() { S s; return s; }
 void main()
 {
 foo.a++;
 }
This is not because of the omittable parens. Even with added parens that code should not compile! L.
Agreed!
Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
Strictly speaking foo.a is an lvalue. Maybe value return types shouldn't be? I think that might be the best keyhole fix.
May 18 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
dsimcha wrote:
 
 Yeah, file a Bugzilla.  Shouldn't ++, +=, etc. only work on lvalues?
*shrug* http://d.puremagic.com/issues/show_bug.cgi?id=3008
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 dsimcha wrote:
 Yeah, file a Bugzilla.  Shouldn't ++, +=, etc. only work on lvalues?
*shrug* http://d.puremagic.com/issues/show_bug.cgi?id=3008
Voted up! Andrei
May 18 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message 
news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
May 18 2009
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:

 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
misuse the omittable parentheses, but what is a "real" property syntax? differently.
May 18 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jesse Phillips escribió:
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:
 
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
misuse the omittable parentheses, but what is a "real" property syntax? differently.
functions, so they don't have side-effects (this is just a contract on the semantic of properties). What that means is that you can invoke them while debugging code and be sure they don't alter the flow of execution. So when watching a variable you automatically can see it's properties, not just it's variables. I find that very useful, since properties basically tell you what's the representation of an object, what's it's meaning (hiding how it is implemented, ultimately). Currently you can't do that in a D debugger because a method like "int foo();" could have side effects. So for me, properties are way more than just syntax sugar.
May 18 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Jesse Phillips escribió:
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:

 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
can misuse the omittable parentheses, but what is a "real" property set up differently.
functions, so they don't have side-effects (this is just a contract on the semantic of properties). What that means is that you can invoke them while debugging code and be sure they don't alter the flow of execution. So when watching a variable you automatically can see it's properties, not just it's variables. I find that very useful, since properties basically tell you what's the representation of an object, what's it's meaning (hiding how it is implemented, ultimately). Currently you can't do that in a D debugger because a method like "int foo();" could have side effects. So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler... -Steve
May 19 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =) I think the actual syntax is really nice and simple, the only thing missing is a way to declare that you expect some function to be a property. Something like this should be enough for me: class C { int no_prop() { return 1; } property int prop() { return 2; } } C c = new C; int x = c.no_prop; // error x = x.prop; // ok "property" should imply "pure". -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 19 2009
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Leandro Lucarella wrote:
 Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
 So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =)
I think that's a dangerous and unnecessarily limiting road to go down. I don't see any benefit from doing this. For example, this would make it impossible to implement a property that lazilly initialised its storage. -- Daniel
May 19 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 19 May 2009 11:12:13 -0300, Leandro Lucarella wrote:

 
 class C
 {
 	int no_prop() { return 1; }
 	property int prop() { return 2; }
 }
 
 C c = new C;
 int x = c.no_prop; // error
 x = x.prop; // ok
 
 "property" should imply "pure".
I actually wouldn't have an issue with this. And if we could get the benefit Ary pointed out, I'd say it would be worth it.
May 19 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 10:12 AM, Leandro Lucarella <llucax gmail.com> wrote:
 Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =)
How the hell do you write a pure setter?
May 19 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el 19 de mayo a las 11:31 me escribiste:
 On Tue, May 19, 2009 at 10:12 AM, Leandro Lucarella <llucax gmail.com> wrote:
 Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =)
How the hell do you write a pure setter?
Ok, "almost pure" =P You should be able to modify "this", of course. BTW, I'm not convinced about it yet, it just looked like something to think about. There is definitely a side of having a contract that a property can't do nasty things that I like, but I'm not convinced that it worth the lost in flexibility. For example, I like ORMs in Python that makes black magic behind the scene to get stuff lazily from the DB. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 19 2009
parent grauzone <none example.net> writes:
 How the hell do you write a pure setter?
Ok, "almost pure" =P You should be able to modify "this", of course.
Properties could be automatically marked as const. Then a setter would not be allowed to change anything, except members explicitly marked with a "mutable" attribute. Oh wait, that doesn't make any sense.
May 19 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 10:12:13 -0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =) I think the actual syntax is really nice and simple, the only thing missing is a way to declare that you expect some function to be a property. Something like this should be enough for me: class C { int no_prop() { return 1; } property int prop() { return 2; } } C c = new C; int x = c.no_prop; // error x = x.prop; // ok "property" should imply "pure".
As Jarrett said, a pure setter is impossible. But, having pure getters even seems like an unnecessary limitation. Having setting and getting grouped together would be nice to me (for documentation/lookup reasons), but not necessary. As long as there's a way to denote "property" versus "function", the scheme works. -Steve
May 19 2009
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Leandro Lucarella wrote:
 Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
 So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
Well, in D2 it would make sense to make mandatory that properties are pure =) I think the actual syntax is really nice and simple, the only thing missing is a way to declare that you expect some function to be a property. Something like this should be enough for me: class C { int no_prop() { return 1; } property int prop() { return 2; } } C c = new C; int x = c.no_prop; // error x = x.prop; // ok "property" should imply "pure".
Well, maybe with "pure" I made a bad choice. The thing is that the instance doesn't seem to change from the outside, from the callee side, but from the inside it might cache something or lazily compute it. But yes, "pure" wouldn't work here.
May 19 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:
 On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Jesse Phillips escribió:
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:

 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
you can misuse the omittable parentheses, but what is a "real" they are just set up differently.
functions, so they don't have side-effects (this is just a contract on the semantic of properties). What that means is that you can invoke them while debugging code and be sure they don't alter the flow of execution. So when watching a variable you automatically can see it's properties, not just it's variables. I find that very useful, since properties basically tell you what's the representation of an object, what's it's meaning (hiding how it is implemented, ultimately). Currently you can't do that in a D debugger because a method like "int foo();" could have side effects. So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write?
May 19 2009
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 13:32:35 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Steven Schveighoffer wrote:
 On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig  
 <ary esperanto.org.ar> wrote:

 Jesse Phillips escribió:
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:

 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
you can misuse the omittable parentheses, but what is a "real" they are just set up differently.
functions, so they don't have side-effects (this is just a contract on the semantic of properties). What that means is that you can invoke them while debugging code and be sure they don't alter the flow of execution. So when watching a variable you automatically can see it's properties, not just it's variables. I find that very useful, since properties basically tell you what's the representation of an object, what's it's meaning (hiding how it is implemented, ultimately). Currently you can't do that in a D debugger because a method like "int foo();" could have side effects. So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write?
Not all the properties I write have side effects :) Most are simply virtual data members. One I just wrote recently is something that returns a unique ID (which changes the next time you access it). I'm unsure what would happen if you read the property during debugging... I suppose I could have made this a function instead, but my point is, if the compiler doesn't enforce it, you can't really rely on the contract. -Steve
May 19 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Ary,

 Steven Schveighoffer wrote:
 
 On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:
 
 Jesse Phillips escribió:
 
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:
 
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 
 Lionello Lunesu wrote:
 
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
 
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
you can misuse the omittable parentheses, but what is a "real" they are just set up differently.
functions, so they don't have side-effects (this is just a contract on the semantic of properties).
AFAIK, this is not enforced by the compiler...
That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write?
You can have side effects, but it makes the code darn near impossible to debug. I've been there and don't plan on going back!
May 19 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Ary Borenszweig wrote:
 That's what I said it's a contract on the semantic of properties. :)
 
 But now I'm curious: what kind of properties do you write?
A getter that does calculations and caches the results (rarely). A proxied getter that does lazy loading from a database table (like NHibernate). Mocks.
May 19 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jesse Phillips" <jessekphillips gmail.com> wrote in message 
news:gutbro$14ev$1 digitalmars.com...
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:
 I still want to get rid of omittable parens (and function-call-as-a-lhs)
 anyway. They're a horrible substitute for a real property syntax.
misuse the omittable parentheses, but what is a "real" property syntax? differently.
D leaves the function/property distinction up to the caller, which is rediculous because in most cases only one or the other actually makes sense. on the callee instead, where it belongs. D's approach is like saying "You can index an array with 'myArray[5]' *or* 'myArray+5', and you can add two numbers with 'myInt+5' *or* 'myInt[5]'. Either way, it's your choice!!". It's a completely useless form of flexibility and comes at the cost of encouraging confusion.
May 19 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Nick Sabalausky wrote:
 D leaves the function/property distinction up to the caller, which is 
 rediculous because in most cases only one or the other actually makes sense. 
I totally agree with this.

 on the callee instead, where it belongs.
this: class C { void set_x(int); int get_x(); int f(); int y; } C c; int i = c.get_x(); // Obviously allowed. i = c.x; // Short for 'c.get_x()'. c.x = i; // Short for 'c.set_x(i)'. i = c.get_y(); // Even this is allowed. c.set_y(i); // And this. //i = c.x(); // But not this. //i = c.f; // And not this. This would still leave choice of syntax on the caller side, but it would remove the ambiguity between method calls and properties. 'c.get_x()' is clearly trying to read a property and 'c.set_x(i)' is clearly trying to set a property, even if they use method call syntax. Unfortunately, this doesn't mesh well with the camelCase capitalization style. I'm not fond of camelCase in the first place, but camelCase seems to be so entrenched in the D culture that there is no hope of ever removing it. -- Rainer Deyke - rainerd eldwood.com
May 19 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 19, 2009 at 1:15 AM, Nick Sabalausky <a a.a> wrote:
 "Jesse Phillips" <jessekphillips gmail.com> wrote in message
 news:gutbro$14ev$1 digitalmars.com...
 On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:
 I still want to get rid of omittable parens (and function-call-as-a-lhs)
 anyway. They're a horrible substitute for a real property syntax.
misuse the omittable parentheses, but what is a "real" property syntax? differently.
D leaves the function/property distinction up to the caller, which is rediculous because in most cases only one or the other actually makes sense. on the callee instead, where it belongs. D's approach is like saying "You can index an array with 'myArray[5]' *or* 'myArray+5', and you can add two numbers with 'myInt+5' *or* 'myInt[5]'.
or 5[myArray] even! (In C/C++ anyway). --bb
May 19 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 05:53:06 +0400, Nick Sabalausky <a a.a> wrote:

 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut1od$l56$1 digitalmars.com...
 Lionello Lunesu wrote:
 "Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message
 news:gut0f2$jc0$1 digitalmars.com...
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
This is not because of the omittable parens. Even with added parens that code should not compile!
Agreed!
I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
Absolutely agree! Most importantly, if we won't be get rid of them right now (before TDPL is out and D2 stabilized), we will have to wait for it to happen until at least D3.
May 19 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Chad J wrote:
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?
 
 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/copy
 (return the value, pass it to a global or function, etc).  It'd be great
 if this kind of thing were a compile time error.
 
 Code like this shouldn't compile:
 
 struct S { int a = 0; }
 S foo() { S s; return s; }
 
 void main()
 {
     foo.a++;
 }
Whatever solution to this is chosen *please* don't make "get", "set", "value" or "prop" into keywords! "in", "out", "body" and "shared" used to be common features of my coding style; I'm not sure it can take another blow. As Andrei mentioned somewhere, keywords aren't cheap.
May 19 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Robert Fraser wrote:
 Chad J wrote:
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?

 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/cop=
y
 (return the value, pass it to a global or function, etc).  It'd be gre=
at
 if this kind of thing were a compile time error.

 Code like this shouldn't compile:

 struct S { int a =3D 0; }
 S foo() { S s; return s; }

 void main()
 {
     foo.a++;
 }
=20 Whatever solution to this is chosen *please* don't make "get", "set",=20 "value" or "prop" into keywords! "in", "out", "body" and "shared" used =
 to be common features of my coding style; I'm not sure it can take=20
 another blow. As Andrei mentioned somewhere, keywords aren't cheap.
How about: int x { setter, getter }; int setter(); void getter (int); Where either one of the accessors may be null (or omitted): int readonly { null, getter }; int writeonly { setter, null }; - It doesn't need a new keyword; - It can't be confused with function declarations because those=20 need parentheses anyway; - Ideally, the compiler would infer the type of the accessor from=20 its prototype (i.e if it doesn't take any arguments and returns T,=20 then it's the getter, if it takes a T and returns void then it's the=20 setter, otherwise it's an error). Of course, this would *not* allocate any space in the class/struct. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
May 19 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Jérôme M. Berger escribió:
 Robert Fraser wrote:
 Chad J wrote:
 Nevermind properties.  Any chance we can forbid the omittable
 parentheses, at least in the lhs of an assignment expression?

 In the more general case, any value type that gets modified but never
 read or copied elsewhere is probably either dead code, a bug, or a
 benchmark.  The latter is easy to fix by adding the necessary read/copy
 (return the value, pass it to a global or function, etc).  It'd be great
 if this kind of thing were a compile time error.

 Code like this shouldn't compile:

 struct S { int a = 0; }
 S foo() { S s; return s; }

 void main()
 {
     foo.a++;
 }
Whatever solution to this is chosen *please* don't make "get", "set", "value" or "prop" into keywords! "in", "out", "body" and "shared" used to be common features of my coding style; I'm not sure it can take another blow. As Andrei mentioned somewhere, keywords aren't cheap.
How about: int x { setter, getter }; int setter(); void getter (int); Where either one of the accessors may be null (or omitted): int readonly { null, getter }; int writeonly { setter, null }; - It doesn't need a new keyword; - It can't be confused with function declarations because those need parentheses anyway; - Ideally, the compiler would infer the type of the accessor from its prototype (i.e if it doesn't take any arguments and returns T, then it's the getter, if it takes a T and returns void then it's the setter, otherwise it's an error). Of course, this would *not* allocate any space in the class/struct. Jerome
Please don't start a subthread about how to implement properties. I think this is the third or fourth time this is discussed here. :) The problem isn't the syntax; the problem is that none of the people who make D see something useful in distinguishing properties from regular function calls without parameters.
May 19 2009