www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Property modifying rvalue

reply Vathix <vathix dprogramming.com> writes:
class Foo
{
    static void prop(inout int x)
    {
       x = 3;
    }
}

int main()
{
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);

    return 0;
}


Output:

num = 0
num = 3


Looks a little backwards ;)  just thought I'd mention it.
May 15 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
I guess it is a feature rather than a bug :)

E.g. it allows to implement transfer of ownership.

struct Foo
{
   char[] _buffer;
   void buffer(inout Foo x)
   {
       _buffer = x._buffer;
       x._buffer = null;
    }
}

Huh?


"Vathix" <vathix dprogramming.com> wrote in message 
news:op.sqt37ts4kcck4r esi...

 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }

 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);

    return 0;
 }


 Output:

 num = 0
 num = 3


 Looks a little backwards ;)  just thought I'd mention it.
May 15 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Vathix wrote:

 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }
 
 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);
 
    return 0;
 }


That looks extremely counterintuitive to me!

What about this idea? The property syntax Foo.prop = num should only be 
allowed where prop takes an in argument. If the argument is out or 
inout, D should force you to use the function syntax Foo.prop(num).

What do you think?

James McComb
May 15 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 09:28:17 +1000, James McComb wrote:


 Vathix wrote:

 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }
 
 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);
 
    return 0;
 }


 
 That looks extremely counterintuitive to me!
 
 What about this idea? The property syntax Foo.prop = num should only be 
 allowed where prop takes an in argument. If the argument is out or 
 inout, D should force you to use the function syntax Foo.prop(num).
 
 What do you think?


It's the designer's or coder's choice. If they choose to use inout *and*
treat it as an inout parameter, that is their choice, and probably made for
a very good reason.

I can't see why we should hobble the language based on 'what is good coding
practices'. If that was the case, the GOTO might not live very long ;-) We
should permit the language to enhance the coder's freedom of coding
practices, even if one doesn't approve of some.

-- 
Derek
Melbourne, Australia
16/05/2005 9:34:02 AM
May 15 2005
next sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Derek Parnell wrote:


 I can't see why we should hobble the language based on 'what is good coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


Hey, I *like* languages that are hobbled based on what is good coding 
practices! It's the only way to guarantee that the other members of my 
team use good pracises (code reviews have no effect on them)! :)

James McComb
May 15 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Are you paying these people?

Who's to say a class couldn't need this, as Andrew Fedoniouk described?

-[Unknown]



 Derek Parnell wrote:
 

 I can't see why we should hobble the language based on 'what is good 
 coding
 practices'. If that was the case, the GOTO might not live very long 
 ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


 
 
 Hey, I *like* languages that are hobbled based on what is good coding 
 practices! It's the only way to guarantee that the other members of my 
 team use good pracises (code reviews have no effect on them)! :)
 
 James McComb
May 15 2005
parent reply James McComb <ned jamesmccomb.id.au> writes:
Unknown W. Brackets wrote:

 Are you paying these people?


No. They're my co-workers.


 Who's to say a class couldn't need this, as Andrew Fedoniouk described?


A class could need that *behaviour*. Why would it need to use property 
*syntax*, when they could use the less confusing (to me, anyway) 
function syntax?

James McComb
May 15 2005
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Ah, there, you said the exact reason - "to me, anyway".  I ain't you.

-[Unknown]



 Who's to say a class couldn't need this, as Andrew Fedoniouk described?


 
 
 A class could need that *behaviour*. Why would it need to use property 
 *syntax*, when they could use the less confusing (to me, anyway) 
 function syntax?
 
 James McComb
May 15 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 A class could need that *behaviour*. Why would it need to use property 
 *syntax*, when they could use the less confusing (to me, anyway) function 
 syntax?


There are a lot of languages passing parameters by values only.
So inout parameter in function will be also weird for apologists of these
languages.


whatewer.

One might say : lets remove references in C++ as memebers of my team
can do:

class Foo {
  void Bar(const T& t) const
  {
     const_cast<Foo*>(this) -> ....
     const_cast<T&>(t). .....
  }
}

All above does not mean that D is perfect at this stage...
It is good, but not perfect yet.

Andrew.


"James McComb" <ned jamesmccomb.id.au> wrote in message 
news:d698bk$121s$1 digitaldaemon.com...

 Unknown W. Brackets wrote:

 Are you paying these people?


 No. They're my co-workers.


 Who's to say a class couldn't need this, as Andrew Fedoniouk described?


 A class could need that *behaviour*. Why would it need to use property 
 *syntax*, when they could use the less confusing (to me, anyway) function 
 syntax?

 James McComb
May 15 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 12:19:35 +1000, James McComb wrote:


 Derek Parnell wrote:
 

 I can't see why we should hobble the language based on 'what is good coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


 
 Hey, I *like* languages that are hobbled based on what is good coding 
 practices! It's the only way to guarantee that the other members of my 
 team use good pracises (code reviews have no effect on them)! :)


Sack them then! A good team plays by the team rules. When team members from
any of my teams have trouble with reviews or following standards, they are
told to shape up or ship out. If they persist in bring down the team, they
are moved off the team.

A flexible language means that different teams can have different rules and
standards. For example, my rules and my standards are not regarded as
sufficient by some other people, and unless they are in one of my teams,
I'm okay with that. They are free to convince me to change my views, as I
believe it is reasonable to assume that my views could possibly be wrong or
need updating.

-- 
Derek
Melbourne, Australia
16/05/2005 12:25:08 PM
May 15 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...

 I can't see why we should hobble the language based on 'what is good 
 coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


Oh come now, D is based around taking all the "gotchas" out of C/C++.  An 
expression such as

blah.x=num;

Where num is affected is a pretty big gotcha if you ask me!

Now, if we were _required_ to state parameters as out or inout when calling 
the functions ;) then this problem wouldn't exist.  It would be 
syntactically illegal to write:

blah.x=inout num;

You would have to write

blah.x(inout num);

Making the intent that num is modified clearer.
May 16 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...

 I can't see why we should hobble the language based on 'what is good 
 coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


 
 Oh come now, D is based around taking all the "gotchas" out of C/C++.  An 
 expression such as
 
 blah.x=num;
 
 Where num is affected is a pretty big gotcha if you ask me!


Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
fairly stupid idea too. However, I cannot make myself start advocating
against it *in every circumstance* because there may very well be a
reasonable justification for it in some special situation that I have yet
to hear about.

To ban it based on the premise that it is a "gotcha" is ammunition to ban
GOTO (and other constructs) from the language too.


 Now, if we were _required_ to state parameters as out or inout when calling 
 the functions ;) then this problem wouldn't exist.  It would be 
 syntactically illegal to write:
 
 blah.x=inout num;
 
 You would have to write
 
 blah.x(inout num);
 
 Making the intent that num is modified clearer.


But if "blah.x=inout num;" is not illegal then this would also express the
coder's intent.

In any case, you can 'ban' it from your code right now by doing ...

   blah.x = (num+0);

-- 
Derek
Melbourne, Australia
17/05/2005 11:33:18 AM
May 16 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:

 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:
 
 

"Derek Parnell" <derek psych.ward> wrote in message 
news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...


I can't see why we should hobble the language based on 'what is good 
coding
practices'. If that was the case, the GOTO might not live very long ;-) We
should permit the language to enhance the coder's freedom of coding
practices, even if one doesn't approve of some.


Oh come now, D is based around taking all the "gotchas" out of C/C++.  An 
expression such as

blah.x=num;

Where num is affected is a pretty big gotcha if you ask me!


 
 
 Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
 fairly stupid idea too. However, I cannot make myself start advocating
 against it *in every circumstance* because there may very well be a
 reasonable justification for it in some special situation that I have yet
 to hear about.
 
 To ban it based on the premise that it is a "gotcha" is ammunition to ban
 GOTO (and other constructs) from the language too.
 
 

Now, if we were _required_ to state parameters as out or inout when calling 
the functions ;) then this problem wouldn't exist.  It would be 
syntactically illegal to write:

blah.x=inout num;

You would have to write

blah.x(inout num);

Making the intent that num is modified clearer.


 
 
 But if "blah.x=inout num;" is not illegal then this would also express the
 coder's intent.
 
 In any case, you can 'ban' it from your code right now by doing ...
 
    blah.x = (num+0);
 


I don't know why you like hackish code, buty um, this has nothing common 
with GOTO.
the GOTO is a low level construct, it's evil, but sometimes you may need 
it when you do low level stuff.
The keyword here is *low level*, D wants to be a systems programming 
language, like C and C++, and not just an application language, like 


properties are (somewhat) high level constructs, there is no rational 
for them to behave unexpectedly.

Just in what way would it help D to have something like
object.propery = value;
change "value" instead of "property"?!
May 16 2005
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Hasan Aljudy wrote:

 Derek Parnell wrote:
 

 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:



 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...


 I can't see why we should hobble the language based on 'what is good 
 coding
 practices'. If that was the case, the GOTO might not live very long 
 ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.



 Oh come now, D is based around taking all the "gotchas" out of 
 C/C++.  An expression such as

 blah.x=num;

 Where num is affected is a pretty big gotcha if you ask me!




 Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
 fairly stupid idea too. However, I cannot make myself start advocating
 against it *in every circumstance* because there may very well be a
 reasonable justification for it in some special situation that I have yet
 to hear about.

 To ban it based on the premise that it is a "gotcha" is ammunition to ban
 GOTO (and other constructs) from the language too.



 Now, if we were _required_ to state parameters as out or inout when 
 calling the functions ;) then this problem wouldn't exist.  It would 
 be syntactically illegal to write:

 blah.x=inout num;

 You would have to write

 blah.x(inout num);

 Making the intent that num is modified clearer.




 But if "blah.x=inout num;" is not illegal then this would also express 
 the
 coder's intent.

 In any case, you can 'ban' it from your code right now by doing ...

    blah.x = (num+0);


 
 I don't know why you like hackish code, buty um, this has nothing common 
 with GOTO.
 the GOTO is a low level construct, it's evil, but sometimes you may need 
 it when you do low level stuff.
 The keyword here is *low level*, D wants to be a systems programming 
 language, like C and C++, and not just an application language, like 

 
 properties are (somewhat) high level constructs, there is no rational 
 for them to behave unexpectedly.
 
 Just in what way would it help D to have something like
 object.propery = value;
 change "value" instead of "property"?!


I forgot to mention that this is just a syntatic sugar, purly a 
syntactic sugar.
There is *NO* situation where it becomes necessary to write
hack.prop = value;
instead of
hack.prop(value);
to change "value".
May 16 2005
parent Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:05:08 -0600, Hasan Aljudy wrote:


 Hasan Aljudy wrote:

 Derek Parnell wrote:
 

 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:



 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...


 I can't see why we should hobble the language based on 'what is good 
 coding
 practices'. If that was the case, the GOTO might not live very long 
 ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.



 Oh come now, D is based around taking all the "gotchas" out of 
 C/C++.  An expression such as

 blah.x=num;

 Where num is affected is a pretty big gotcha if you ask me!




 Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
 fairly stupid idea too. However, I cannot make myself start advocating
 against it *in every circumstance* because there may very well be a
 reasonable justification for it in some special situation that I have yet
 to hear about.

 To ban it based on the premise that it is a "gotcha" is ammunition to ban
 GOTO (and other constructs) from the language too.



 Now, if we were _required_ to state parameters as out or inout when 
 calling the functions ;) then this problem wouldn't exist.  It would 
 be syntactically illegal to write:

 blah.x=inout num;

 You would have to write

 blah.x(inout num);

 Making the intent that num is modified clearer.




 But if "blah.x=inout num;" is not illegal then this would also express 
 the
 coder's intent.

 In any case, you can 'ban' it from your code right now by doing ...

    blah.x = (num+0);


 
 I don't know why you like hackish code, buty um, this has nothing common 
 with GOTO.
 the GOTO is a low level construct, it's evil, but sometimes you may need 
 it when you do low level stuff.
 The keyword here is *low level*, D wants to be a systems programming 
 language, like C and C++, and not just an application language, like 

 
 properties are (somewhat) high level constructs, there is no rational 
 for them to behave unexpectedly.
 
 Just in what way would it help D to have something like
 object.propery = value;
 change "value" instead of "property"?!


 
 I forgot to mention that this is just a syntatic sugar, purly a 
 syntactic sugar.
 There is *NO* situation where it becomes necessary to write
 hack.prop = value;
 instead of
 hack.prop(value);
 to change "value".


That maybe true. And there is also no reason to code "value++" instead of
"value = value + 1"

-- 
Derek
Melbourne, Australia
17/05/2005 1:40:27 PM
May 16 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:01:53 -0600, Hasan Aljudy wrote:


 Derek Parnell wrote:


[snip]


 Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
 fairly stupid idea too. However, I cannot make myself start advocating
 against it *in every circumstance* because there may very well be a
 reasonable justification for it in some special situation that I have yet
 to hear about.
 
 To ban it based on the premise that it is a "gotcha" is ammunition to ban
 GOTO (and other constructs) from the language too.
 




[snip]
 

 I don't know why you like hackish code, buty um, this has nothing common 
 with GOTO.


Who said I liked "hackish" code? ;-)


 the GOTO is a low level construct, it's evil, but sometimes you may need 
 it when you do low level stuff.


GOTO is not evil because it is low-level; it is evil because it tends to
increase the cost of maintaining code.


 The keyword here is *low level*, D wants to be a systems programming 
 language, like C and C++, and not just an application language, like 

 
 properties are (somewhat) high level constructs, there is no rational 
 for them to behave unexpectedly.
 
 Just in what way would it help D to have something like
 object.propery = value;
 change "value" instead of "property"?!


I have no idea at all in what way this might help D. But because of the
fact that I don't know, does not automatically mean that there is no good
reason for it, it just means that I don't know it. Somebody else might know
or discover it.

Anyhow, if it coded as "object.property = inout value;" the reader would be
aware of potential side-effects.

Consider ...

  object.property = ++value;

This also modifies the right hand side identifier, but because of the "++"
prefix the reader is made aware of that. 

-- 
Derek
Melbourne, Australia
17/05/2005 1:31:35 PM
May 16 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:

 On Mon, 16 May 2005 21:01:53 -0600, Hasan Aljudy wrote:
 
 

Derek Parnell wrote:


 
 
 [snip]
 
 

Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
fairly stupid idea too. However, I cannot make myself start advocating
against it *in every circumstance* because there may very well be a
reasonable justification for it in some special situation that I have yet
to hear about.

To ban it based on the premise that it is a "gotcha" is ammunition to ban
GOTO (and other constructs) from the language too.




 
 
 [snip]
  
 

I don't know why you like hackish code, buty um, this has nothing common 
with GOTO.


 
 
 Who said I liked "hackish" code? ;-)
 
 

the GOTO is a low level construct, it's evil, but sometimes you may need 
it when you do low level stuff.


 
 
 GOTO is not evil because it is low-level; it is evil because it tends to
 increase the cost of maintaining code.
 
 

The keyword here is *low level*, D wants to be a systems programming 
language, like C and C++, and not just an application language, like 


properties are (somewhat) high level constructs, there is no rational 
for them to behave unexpectedly.

Just in what way would it help D to have something like
object.propery = value;
change "value" instead of "property"?!


 
 
 I have no idea at all in what way this might help D. But because of the
 fact that I don't know, does not automatically mean that there is no good
 reason for it, it just means that I don't know it. Somebody else might know
 or discover it.


Like I said, it's just a syntactic sugar, it doesn't do anything 
differently, so there is nothing to discover, except maybe for the 
ability to produce obfuscated code.
All you're doing is removing the brckets and adding an "=" equals sign.
What would be the circumistance where it becomes usefully more 
benefitial than obj.prop(val);

It's a syntactic sugar, it adds no new abilities to the language.


 
 Anyhow, if it coded as "object.property = inout value;" the reader would be
 aware of potential side-effects.


I would rather have the compiler produce an error if a function is 
defiend like this:
property(out value) [...]
and called like this:
property = value;

The simple solution is that this property syntactic sugar is only legal 
when value is not "out" i.e. when the compiler knows that the method 
"property" does not change "value".

the suggestion
object.property = inout value;
is just pointless, it's not a syntactic sugar, it's a syntactic 
complication.
What's the point of it? If we're gonna do that, we might as well just 
get rid of this sugar as a whole.


 
 Consider ...
 
   object.property = ++value;
 
 This also modifies the right hand side identifier, but because of the "++"
 prefix the reader is made aware of that. 
 


This is different, ++value is an expression that returns a value, it's 
not a variable. Just like:
obj.prop = val = x;
(I don't know if that's legal in D)
Where (val = x) is an expression that returns a value (returns x).
May 16 2005
prev sibling parent reply Brian White <bcwhite precidia.com> writes:
What about this idea? The property syntax Foo.prop = num should only be 
allowed where prop takes an in argument. If the argument is out or 
inout, D should force you to use the function syntax Foo.prop(num).




I think that would be just fine.  Personally, I think banning all calls 
to functions via "=" would be fine, too, but it's not a big deal. 
However, in the case where an offending line looks perfectly innocent 
and has such a potentially disasterous side-effect, then it should 
definitely be banned.

As someone else said, part of D's philosophy is to remove "gotchas".



 It's the designer's or coder's choice. If they choose to use inout *and*
 treat it as an inout parameter, that is their choice, and probably made for
 a very good reason.


It may not be a designer's choice.  The code could be a module written 
by someone else and imported.  An assignment should not modify an 
rvalue.  If you can provide some examples of those "very good reasons", 
I'd appreciate it.



 I can't see why we should hobble the language based on 'what is good coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


All languages are hobbled.  This restricts nothing since a slightly 
different syntax accomplishes the exact same thing and with much better 
clarity.  Let's not have people shooting themselves in the foot when 
they don't even realize that what they're holding is a gun.

                                           Brian
                                  ( bcwhite precidia.com )

-------------------------------------------------------------------------------
     In theory, theory and practice are the same.  In practice, they're not.
May 18 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Brian White" <bcwhite precidia.com> wrote in message 
news:d6g56c$3mt$1 digitaldaemon.com...

What about this idea? The property syntax Foo.prop = num should only be 
allowed where prop takes an in argument. If the argument is out or inout, 
D should force you to use the function syntax Foo.prop(num).




 I think that would be just fine.  Personally, I think banning all calls to 
 functions via "=" would be fine, too, but it's not a big deal. However, in 
 the case where an offending line looks perfectly innocent and has such a 
 potentially disasterous side-effect, then it should definitely be banned.

 As someone else said, part of D's philosophy is to remove "gotchas".


Keep in mind there are many ways to abuse inout with innocent looking 
syntax. For example operator overloading can be used:

struct Foo {
    int opAdd(inout int y) { y = 10; return 20;}
}
int main() {
    Foo x;
    int y = 1;
    int z = x+y; // changes y
    assert( y == 10 );
    return 0;
}

I think in this case if people want to abuse inout and syntacitc sugar they 
can.
May 18 2005
parent Vathix <vathix dprogramming.com> writes:
 Keep in mind there are many ways to abuse inout with innocent looking
 syntax. For example operator overloading can be used:

 struct Foo {
     int opAdd(inout int y) { y = 10; return 20;}
 }
 int main() {
     Foo x;
     int y = 1;
     int z = x+y; // changes y
     assert( y == 10 );
     return 0;
 }

 I think in this case if people want to abuse inout and syntacitc sugar  
 they
 can.


This might be a reason to require function callers to specify out/inout,  
and it would be impossible to specify that for properties and overloaded  
operators, as a nice little side affect. For example:


class Foo
{
    static void func(inout int x)
    {
       x = 4;
    }
    static void prop(inout int x)
    {
       x = 3;
    }
}

int main()
{
    int num;
    Foo.func(num); // error: must specify inout.
    Foo.func(inout num);
    Foo.prop = num; // error: must specify inout.
    Foo.prop = inout num; // error: bad syntax.
    return 0;
}
May 18 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 18 May 2005 15:31:24 -0400, Brian White wrote:


What about this idea? The property syntax Foo.prop = num should only be 
allowed where prop takes an in argument. If the argument is out or 
inout, D should force you to use the function syntax Foo.prop(num).




 
 I think that would be just fine.  Personally, I think banning all calls 
 to functions via "=" would be fine, too, but it's not a big deal. 
 However, in the case where an offending line looks perfectly innocent 
 and has such a potentially disasterous side-effect, then it should 
 definitely be banned.
 
 As someone else said, part of D's philosophy is to remove "gotchas".


Right, like "Foo a; a.Bar();"  ;-)


 

 It's the designer's or coder's choice. If they choose to use inout *and*
 treat it as an inout parameter, that is their choice, and probably made for
 a very good reason.


 
 It may not be a designer's choice.  The code could be a module written 
 by someone else and imported.  An assignment should not modify an 
 rvalue.  If you can provide some examples of those "very good reasons", 
 I'd appreciate it.


I've already said that I can't do that because I don't know any. But just
because I don't know any doesn't automatically mean that there aren't any.
 

 

 I can't see why we should hobble the language based on 'what is good coding
 practices'. If that was the case, the GOTO might not live very long ;-) We
 should permit the language to enhance the coder's freedom of coding
 practices, even if one doesn't approve of some.


 
 All languages are hobbled.


I know. Do you think I said otherwise?

I did say (to paraphrase) "restricting a languages syntax based only on
what some people regard as poor coding standards is not to be encouraged".


  This restricts nothing since a slightly 
 different syntax accomplishes the exact same thing and with much better 
 clarity.  


Just to clarify, doesn't 'restrict' mean 'prevent full access or usage'.
Therefore I would think that preventing access *to this syntax* is actually
a restriction.


 Let's not have people shooting themselves in the foot when 
 they don't even realize that what they're holding is a gun.


The same reasoning could be used to ban the use of assembler coding.
I believe the risk-mitigation strategies for this are called
'documentation' and 'education'.

-- 
Derek Parnell
Melbourne, Australia
19/05/2005 6:51:04 AM
May 18 2005
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:
[snip]

 The same reasoning could be used to ban the use of assembler coding.
 I believe the risk-mitigation strategies for this are called
 'documentation' and 'education'.
 



Well, the reason I liked D and go into it was because it removes all the 
"gotchas" from C/C++ (well, not /all/ of them) but that's something that 
is needed in a new language like D. Or else, what's the use of it? We 
can just stick to C++.

http://www.digitalmars.com/d/overview.html

I also like D for not being toooo restrictive (like Java).

But restrictions are not necessarily a bad thing.

I don't think that disallowing the property behaviour on methods that 
take an inout/out parameter is a bad restriction, it's a good restriction.
The property syntax sugar (as I understand) is for redundant accessor 
methods on classes, it's meant to simplify things, not complicate them.

The problem here is that it's really hard to assume that
obj.prop = value;
would change the value .. this just bloats the language with "gotchas". 
What's the purpose then?

Like I said again and again, there can be no cases where this type of 
syntax becomes necessary, it's just a sugar, not a feature.
May 18 2005
prev sibling parent Brian White <bcwhite precidia.com> writes:
What about this idea? The property syntax Foo.prop = num should only be 
allowed where prop takes an in argument. If the argument is out or 
inout, D should force you to use the function syntax Foo.prop(num).




I think that would be just fine.  Personally, I think banning all calls 
to functions via "=" would be fine, too, but it's not a big deal. 
However, in the case where an offending line looks perfectly innocent 
and has such a potentially disasterous side-effect, then it should 
definitely be banned.

As someone else said, part of D's philosophy is to remove "gotchas".


 
 Right, like "Foo a; a.Bar();"  ;-)


Unfortunately, D is not entirely successful in its attempt.  I also made 
a post yesterday about this ambiguity (which may be what the ";-)" is 
about or it may be because I was bitten by this... not sure) on D.learn. 
  Search the subjects for "opEquals ambiguity" and you should find it.

But not being entirely successful doesn't provide reason to be more 
unsuccessful.



It's the designer's or coder's choice. If they choose to use inout *and*
treat it as an inout parameter, that is their choice, and probably made for
a very good reason.


It may not be a designer's choice.  The code could be a module written 
by someone else and imported.  An assignment should not modify an 
rvalue.  If you can provide some examples of those "very good reasons", 
I'd appreciate it.


 
 I've already said that I can't do that because I don't know any. But just
 because I don't know any doesn't automatically mean that there aren't any.


Well... I don't recall anybody providing good reasons.  So, with very 
good reasons why this can be problematic, complete absense of evidence 
to the contrary, and a perfectly legal alternate syntax that at least 
hints of possible side-effects...  Why allow it to be used?



 I did say (to paraphrase) "restricting a languages syntax based only on
 what some people regard as poor coding standards is not to be 


encouraged".

 This restricts nothing since a slightly 
different syntax accomplishes the exact same thing and with much better 
clarity.  


 
 Just to clarify, doesn't 'restrict' mean 'prevent full access or usage'.
 Therefore I would think that preventing access *to this syntax* is actually
 a restriction.


Okay...  Let me define "restrict" as "limiting the coder in what can be 
accomplished".  Then, there is no restriction because the exact same 
thing can be accomplished with a different and better (because it at 
least hints that it may be modified since all paramaters can be) syntax.



Let's not have people shooting themselves in the foot when 
they don't even realize that what they're holding is a gun.


 
 The same reasoning could be used to ban the use of assembler coding.
 I believe the risk-mitigation strategies for this are called
 'documentation' and 'education'.


I'd say that when you code in assembler, you _know_ you're holding a 
gun.  I'd also say that you're doing it because there is no other way to 
accomplish the desired results.

                                           Brian
                                  ( bcwhite precidia.com )

-------------------------------------------------------------------------------
  "I can't complain but sometimes I still do."  -- Joe Walsh (Life's 
Been Good)
May 19 2005