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. This feature makes C# much easier to read..
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.

 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.
 This feature makes C# much easier to read..

how successful it is there. Also I don't think C# has & or * so ref 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 ;)
 I am curious about the experience in C#. I haven't used C# so I have no 
 idea how successful it is there. Also I don't think C# has & or * so ref 
 parameters are the only way to pass value types by reference.

I haven't done much with C# either (nor do I know many people who have), but you're right, C# has the 'ref' keyword, equivalent of 'inout' in D. It 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 ;)
Jul 13 2005
parent reply Niko Korhonen <niktheblak hotmail.com> writes:
Jarrett Billingsley wrote:
  > I haven't done much with C# either (nor do I know many people who 
have), but
 you're right, C# has the 'ref' keyword, equivalent of 'inout' in D.  It 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 ;) 

I've used C# (1.1/2.0) extensively and I really think that the mandatory 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. Other thing that I love with C# is the mandatory override specifier. But 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:
   > I haven't done much with C# either (nor do I know many people who  
 have), but
 you're right, C# has the 'ref' keyword, equivalent of 'inout' in D.  It  
 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 ;)

I've used C# (1.1/2.0) extensively and I really think that the mandatory 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.
 Other thing that I love with C# is the mandatory override specifier. But  
 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