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.

"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..

"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.

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

"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 ;)

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

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

"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.

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