www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - in/out/inout at call site

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
It would be nice if one could optionally put in/out/inout at the call site 
in front of in/out/inout parameters. For example
  bool foo(in int a, out int b){...}
  ...
  int x;
  if (foo(10,out x)) ...
It wouldn't be required to put it in but it could make the user code more 
maintainable.
Jul 13 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:db3f2d$ik1$1 digitaldaemon.com...

 It would be nice if one could optionally put in/out/inout at the call site 
 in front of in/out/inout parameters. For example
  bool foo(in int a, out int b){...}
  ...
  int x;
  if (foo(10,out x)) ...
 It wouldn't be required to put it in but it could make the user code more 
 maintainable.


I think I suggested this as well, and I'd like to see it.  However, it'd 
have to be made mandatory for it to be of any use.  If you could write

foo(10, out x)

and

foo(10,x)

and have them be semantically equivalent, it'd be confusing and a half.

Additionally, making the out/inout required at call-time would also enable 
overloading of functions based on parameter inout type.  I.e.

void fork(int x)
{

}

void fork(inout int x)
{

}

A minor plus, but a plus nonetheless.
Jul 13 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:db3v7d$1037$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
 news:db3f2d$ik1$1 digitaldaemon.com...

 It would be nice if one could optionally put in/out/inout at the call 
 site in front of in/out/inout parameters. For example
  bool foo(in int a, out int b){...}
  ...
  int x;
  if (foo(10,out x)) ...
 It wouldn't be required to put it in but it could make the user code more 
 maintainable.


 I think I suggested this as well, and I'd like to see it.


yeah - I was too lazy to search the archives. sorry about that.


 However, it'd have to be made mandatory for it to be of any use.  If you 
 could write

 foo(10, out x)

 and

 foo(10,x)

 and have them be semantically equivalent, it'd be confusing and a half.


I can see that if one assumes the lack of inout/out means the param must be 
in then yes I agree. I was thinking of it more like an extra hint to the 
code maintainer in case the context wasn't obvious that an argument was an 
inout/out. I think explicit inout/out would be annoying since in that case 
there is very little difference between inout/out and taking a pointer.


 Additionally, making the out/inout required at call-time would also enable 
 overloading of functions based on parameter inout type.


That is what would scare me actually.







parameters are the only way to pass value types by reference.
Jul 13 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:db4fg7$1cmp$1 digitaldaemon.com...

 yeah - I was too lazy to search the archives. sorry about that.


Oh well.  It's not like the matter was receiving any attention in the 
archives ;)


 I can see that if one assumes the lack of inout/out means the param must 
 be in then yes I agree. I was thinking of it more like an extra hint to 
 the code maintainer in case the context wasn't obvious that an argument 
 was an inout/out. I think explicit inout/out would be annoying since in 
 that case there is very little difference between inout/out and taking a 
 pointer.


I'm curious to know why you feel that way, as I've always been a bit wary of 
using out/inout myself, simply because it's never obvious that the parameter 
_is_ out/inout.  With pointers, you have to use the &, which makes it quite 
obvious that something's probably going to happen to the parameter. 
out/inout seem like a natural extension of that, except that it's even 
clearer what's going to happen - namely, that it's going to be modified, or 
it's a return value.  out/inout serve not only functionally, but also as a 
way of self-documenting code - though it's not much of a use if it's only 
self-documented in one location!


 That is what would scare me actually.


That would scare me too, and I'm sorry I mentioned it ;)




 parameters are the only way to pass value types by reference.




has the 'out' keyword.  And as far as I know, both of which are needed at 
call-time as well as in the function declaration.  And believe me, it makes 
it easier to understand, especially when you've never looked at the language 
before ;)
Jul 13 2005
parent reply Niko Korhonen <niktheblak hotmail.com> writes:
Jarrett Billingsley wrote:

have), but


 has the 'out' keyword.  And as far as I know, both of which are needed at 
 call-time as well as in the function declaration.  And believe me, it makes 
 it easier to understand, especially when you've never looked at the language 
 before ;) 



ref/out at the caller site is a good idea. Ref/out arguments don't get 
used *that* often to generate any mentionable clutter in the code, and 
when they are used, it's really good to clearly document the intent.


on the other hand, I hate the need to explicitly state that a function 
is virtual; that's so C++. D's 'virtual by default' with mandatory 
override specifier would be the best possible thing IMHO.

Not having a mandatory override specifier basically puts you at the 
mercy of the IDE to figure out whether a function overrides it's 
ancestor or not. When you're not using an IDE, things get really fun, 
especially if typos are involved.

D currently has optional override specifier, which I use extensively and 
wish for it to become mandatory in the future.

-- 
Niko Korhonen
SW Developer
Jul 14 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Jul 2005 12:29:20 +0300, Niko Korhonen <niktheblak hotmail.com>  
wrote:

 Jarrett Billingsley wrote:

 have), but


 also has the 'out' keyword.  And as far as I know, both of which are  
 needed at call-time as well as in the function declaration.  And  
 believe me, it makes it easier to understand, especially when you've  
 never looked at the language before ;)



 ref/out at the caller site is a good idea. Ref/out arguments don't get  
 used *that* often to generate any mentionable clutter in the code, and  
 when they are used, it's really good to clearly document the intent.


I don't have a strong opinion here except to say that I haven't really had  
many problems that have arisen from me not knowing what type of parameter  
it was. A good IDE should be able to make these more obvious. i.e popup  
function declaration as you type, highlight in, out and inout different  
colours, etc.



 on the other hand, I hate the need to explicitly state that a function  
 is virtual; that's so C++. D's 'virtual by default' with mandatory  
 override specifier would be the best possible thing IMHO.

 Not having a mandatory override specifier basically puts you at the  
 mercy of the IDE to figure out whether a function overrides it's  
 ancestor or not. When you're not using an IDE, things get really fun,  
 especially if typos are involved.

 D currently has optional override specifier, which I use extensively and  
 wish for it to become mandatory in the future.


I think override should be mandatory also.

Regan
Jul 14 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opstwjlgpg23k2f5 nrage.netwin.co.nz...

 I don't have a strong opinion here except to say that I haven't really had 
 many problems that have arisen from me not knowing what type of parameter 
 it was. A good IDE should be able to make these more obvious. i.e popup 
 function declaration as you type, highlight in, out and inout different 
 colours, etc.


That'd be great if D _had_ an IDE.. ;)


 I think override should be mandatory also.


Agreed.
Jul 14 2005
parent Niko Korhonen <niktheblak hotmail.com> writes:
Jarrett Billingsley wrote:

 That'd be great if D _had_ an IDE.. ;)


A thought of pointing this fact out did cross my mind but I decided to 
refrain myself :)

Actually I have very little trouble developing a pretty hefty 
application in D just with a text editor. For some reason (most likely 
Walter's bright design :) ) D is really easy to type even without 
standard IntelliSense-like IDE features.

The same applies for plain C too, at least in my book; C and D are 
somehow very "writeable". D remains the more readable of these two, 
however :)

-- 
Niko Korhonen
SW Developer
Jul 14 2005