digitalmars.D - While we're lynching features, how bout' them omittable parens?
- Chad J <chadjoan __spam.is.bad__gmail.com> May 18 2009
- "Lionello Lunesu" <lionello lunesu.remove.com> May 18 2009
- Chad J <chadjoan __spam.is.bad__gmail.com> May 18 2009
- dsimcha <dsimcha yahoo.com> May 18 2009
- BCS <none anon.com> May 18 2009
- Chad J <chadjoan __spam.is.bad__gmail.com> May 18 2009
- "Nick Sabalausky" <a a.a> May 18 2009
- Ary Borenszweig <ary esperanto.org.ar> May 18 2009
- Leandro Lucarella <llucax gmail.com> May 19 2009
- Daniel Keep <daniel.keep.lists gmail.com> May 19 2009
- Ary Borenszweig <ary esperanto.org.ar> May 19 2009
- Leandro Lucarella <llucax gmail.com> May 19 2009
- grauzone <none example.net> May 19 2009
- Ary Borenszweig <ary esperanto.org.ar> May 19 2009
- BCS <ao pathlink.com> May 19 2009
- Christopher Wright <dhasenan gmail.com> May 19 2009
- "Nick Sabalausky" <a a.a> May 19 2009
- Rainer Deyke <rainerd eldwood.com> May 19 2009
- Jesse Phillips <jessekphillips gmail.com> May 18 2009
- "Denis Koroskin" <2korden gmail.com> May 19 2009
- "Steven Schveighoffer" <schveiguy yahoo.com> May 19 2009
- Bill Baxter <wbaxter gmail.com> May 19 2009
- Jesse Phillips <jessekphillips gmail.com> May 19 2009
- Jarrett Billingsley <jarrett.billingsley gmail.com> May 19 2009
- "Steven Schveighoffer" <schveiguy yahoo.com> May 19 2009
- "Steven Schveighoffer" <schveiguy yahoo.com> May 19 2009
- Robert Fraser <fraserofthenight gmail.com> May 19 2009
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...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
== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s articleLionello 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.
Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
May 18 2009
BCS <none anon.com> Hello dsimcha,== Quote from Chad J (chadjoan __spam.is.bad__gmail.com)'s articleLionello 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++; }
that code should not compile! L.
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
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: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
"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
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?
that code should not compile!
anyway. They're a horrible substitute for a real property syntax.
I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
What I like in C# about properties is that they are like "pure" 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
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... I write C# properties that have side effects.
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
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.
I write C# properties that have side effects.
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
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.
I write C# properties that have side effects.
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
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... I write C# properties that have side effects.
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
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
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?
that code should not compile!
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" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
What I like in C# about properties is that they are like "pure" 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... I write C# properties that have side effects.
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
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?
parens that code should not compile!
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" property syntax? Seems to me both D and C# provide the same syntax 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... I write C# properties that have side effects.
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
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: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.
I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up 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. C# places the responsilibily for that function-syntax/property-syntax choice 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
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.C# places the responsilibily for that function-syntax/property-syntax choice on the callee instead, where it belongs.
C#'s properties are a bit syntax-heavy for my taste. I'd be happy with 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 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?
that code should not compile!
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.
I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
May 18 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...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
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?
that code should not compile!
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 syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
What I like in C# about properties is that they are like "pure" 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... I write C# properties that have side effects. -Steve
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...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.
I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up 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. C# places the responsilibily for that function-syntax/property-syntax choice 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
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:So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler... I write C# properties that have side effects.
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
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... I write C# properties that have side effects.
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
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?
that code should not compile!
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" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
What I like in C# about properties is that they are like "pure" 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.
I write C# properties that have side effects.
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
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
Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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=
(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++; }
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: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