digitalmars.D - While we're lynching features, how bout' them omittable parens?
- Chad J (14/14) May 18 2009 Nevermind properties. Any chance we can forbid the omittable
- Lionello Lunesu (5/19) May 18 2009 This is not because of the omittable parens. Even with added parens that...
- Chad J (2/28) May 18 2009 Agreed!
- dsimcha (2/30) May 18 2009 Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
- BCS (3/36) May 18 2009 Strictly speaking foo.a is an lvalue. Maybe value return types shouldn't...
- Chad J (3/5) May 18 2009 *shrug*
- Andrei Alexandrescu (3/9) May 18 2009 Voted up!
- Nick Sabalausky (4/16) May 18 2009 I still want to get rid of omittable parens (and function-call-as-a-lhs)...
- Jesse Phillips (5/23) May 18 2009 I don't like C# properties, IMO it is pointless overhead. I agree you ca...
- Ary Borenszweig (12/35) May 18 2009 What I like in C# about properties is that they are like "pure"
- Steven Schveighoffer (5/40) May 19 2009 AFAIK, this is not enforced by the compiler...
- Leandro Lucarella (21/26) May 19 2009 Well, in D2 it would make sense to make mandatory that properties are pu...
- Daniel Keep (6/14) May 19 2009 I think that's a dangerous and unnecessarily limiting road to go down.
- Jesse Phillips (3/15) May 19 2009 I actually wouldn't have an issue with this. And if we could get the
- Jarrett Billingsley (2/10) May 19 2009 How the hell do you write a pure setter?
- Leandro Lucarella (13/25) May 19 2009 Ok, "almost pure" =P
- grauzone (4/9) May 19 2009 Properties could be automatically marked as const. Then a setter would
- Steven Schveighoffer (8/30) May 19 2009 As Jarrett said, a pure setter is impossible. But, having pure getters ...
- Ary Borenszweig (5/32) May 19 2009 Well, maybe with "pure" I made a bad choice. The thing is that the
- Ary Borenszweig (3/48) May 19 2009 That's what I said it's a contract on the semantic of properties. :)
- Steven Schveighoffer (10/56) May 19 2009 Not all the properties I write have side effects :) Most are simply
- BCS (3/48) May 19 2009 You can have side effects, but it makes the code darn near impossible to...
- Christopher Wright (5/8) May 19 2009 A getter that does calculations and caches the results (rarely).
- Nick Sabalausky (10/18) May 19 2009 D leaves the function/property distinction up to the caller, which is
- Rainer Deyke (28/32) May 19 2009 C#'s properties are a bit syntax-heavy for my taste. I'd be happy with
- Bill Baxter (3/20) May 19 2009 or 5[myArray] even! (In C/C++ anyway).
- Denis Koroskin (2/20) May 19 2009 Absolutely agree! Most importantly, if we won't be get rid of them right...
- Robert Fraser (5/23) May 19 2009 Whatever solution to this is chosen *please* don't make "get", "set",
- =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= (23/47) May 19 2009 at
- Ary Borenszweig (6/54) May 19 2009 Please don't start a subthread about how to implement properties. I
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
"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
Lionello Lunesu wrote:"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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
== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s articleLionello Lunesu wrote:Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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
Hello dsimcha,== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s articleStrictly speaking foo.a is an lvalue. Maybe value return types shouldn't be? I think that might be the best keyhole fix.Lionello Lunesu wrote:Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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
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
Chad J wrote:dsimcha wrote:Voted up! AndreiYeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?*shrug* http://d.puremagic.com/issues/show_bug.cgi?id=3008
May 18 2009
"Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 18 2009
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...misuse the omittable parentheses, but what is a "real" property syntax? differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 18 2009
Jesse Phillips escribió:On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...misuse the omittable parentheses, but what is a "real" property syntax? differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 18 2009
On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig <ary esperanto.org.ar> wrote:Jesse Phillips escribió:AFAIK, this is not enforced by the compiler... -SteveOn Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...can misuse the omittable parentheses, but what is a "real" property set up differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 19 2009
Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: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) ----------------------------------------------------------------------------So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
Leandro Lucarella wrote:Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: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. -- DanielWell, in D2 it would make sense to make mandatory that properties are pure =)So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
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
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:How the hell do you write a pure setter?Well, in D2 it would make sense to make mandatory that properties are pure =)So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
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: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) ----------------------------------------------------------------------------Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:How the hell do you write a pure setter?Well, in D2 it would make sense to make mandatory that properties are pure =)So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
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.How the hell do you write a pure setter?Ok, "almost pure" =P You should be able to modify "this", of course.
May 19 2009
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: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. -SteveWell, 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".So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
Leandro Lucarella wrote:Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: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.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".So for me, properties are way more than just syntax sugar.AFAIK, this is not enforced by the compiler...
May 19 2009
Steven Schveighoffer wrote:On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig <ary esperanto.org.ar> 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?Jesse Phillips escribió:AFAIK, this is not enforced by the compiler...On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...you can misuse the omittable parentheses, but what is a "real" they are just set up differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 19 2009
On Tue, 19 May 2009 13:32:35 -0400, Ary Borenszweig <ary esperanto.org.ar> wrote:Steven Schveighoffer wrote: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. -SteveOn Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig <ary esperanto.org.ar> 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?Jesse Phillips escribió:AFAIK, this is not enforced by the compiler...On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...you can misuse the omittable parentheses, but what is a "real" they are just set up differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 19 2009
Reply to Ary,Steven Schveighoffer wrote: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!On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig <ary esperanto.org.ar> 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?Jesse Phillips escribió:AFAIK, this is not enforced by the compiler...On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote:functions, so they don't have side-effects (this is just a contract on the semantic of properties)."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut1od$l56$1 digitalmars.com...you can misuse the omittable parentheses, but what is a "real" they are just set up differently.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 19 2009
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
"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: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.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 19 2009
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
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...or 5[myArray] even! (In C/C++ anyway). --bbOn Mon, 18 May 2009 21:53:06 -0400, 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. 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]'.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 19 2009
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...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.Lionello Lunesu 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."Chad J" <chadjoan __spam.is.bad__gmail.com> wrote in message news:gut0f2$jc0$1 digitalmars.com...Agreed!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!
May 19 2009
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
Robert Fraser wrote:Chad J wrote:yNevermind 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=at(return the value, pass it to a global or function, etc). It'd be gre=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
Jérôme M. Berger escribió:Robert Fraser wrote: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.Chad J wrote: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. JeromeNevermind 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