I like D's in/out/inout function parameter modifiers.  However, I think that it would be good to allow the caller to add an "in" "out" or "inout" prefix to any or all arguments.  This allows the caller to document, in the code, how the parameter is to be used.  It would be a syntax error to call a function where one of the parameters didn't match the function definition; if you don't specify a prefix, that's ok.

This would make the caller's code easier to read, since it would implicitly document which parameters are out or inout parameters.  It would also pick up bugs that might otherwise happen if the interface changed.

Not only that, it would make it possible to overload based on the in/out/inout parameter, although I'm not convinced that's really a good idea.

BUT I REALLY THINK...

That the appropriate prefix should be REQUIRED for any out or inout parameters.  If we go this way, then not having a prefix is the same as explicitly having an "in" prefix.

Thoughts?

It's an interesting idea. Some may complain that it's enough to specify out and inout in the function, that it's just too much typing to do it everywhere the function gets called.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D94BAF6.80803@deming-os.org...
> I like D's in/out/inout function parameter modifiers.  However, I think that it would be good to allow the caller to add an "in" "out" or "inout" prefix to any or all arguments.  This allows the caller to document, in the code, how the parameter is to be used.  It would be a syntax error to call a function where one of the parameters didn't match the function definition; if you don't specify a prefix, that's ok.
>
> This would make the caller's code easier to read, since it would implicitly document which parameters are out or inout parameters.  It would also pick up bugs that might otherwise happen if the interface changed.
>
> Not only that, it would make it possible to overload based on the in/out/inout parameter, although I'm not convinced that's really a good idea.
>
> BUT I REALLY THINK...
>
> That the appropriate prefix should be REQUIRED for any out or inout parameters.  If we go this way, then not having a prefix is the same as explicitly having an "in" prefix.
>
> Thoughts?
>

I agree that 'out' and 'inout' should be required in calls for both reasons you sugest.

And I propose the 'in' be droped altogether as it is implicit and hence redunant just as nobody uses 'auto' in C. I would also prefer 'ref' to 'inout', but thats just personal preferance i guese.

chris


"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D94BAF6.80803@deming-os.org...
> I like D's in/out/inout function parameter modifiers.  However, I think that it would be good to allow the caller to add an "in" "out" or "inout" prefix to any or all arguments.  This allows the caller to document, in the code, how the parameter is to be used.  It would be a syntax error to call a function where one of the parameters didn't match the function definition; if you don't specify a prefix, that's ok.
>
> This would make the caller's code easier to read, since it would implicitly document which parameters are out or inout parameters.  It would also pick up bugs that might otherwise happen if the interface changed.
>
> Not only that, it would make it possible to overload based on the in/out/inout parameter, although I'm not convinced that's really a good idea.
>
> BUT I REALLY THINK...
>
> That the appropriate prefix should be REQUIRED for any out or inout parameters.  If we go this way, then not having a prefix is the same as explicitly having an "in" prefix.
>
> Thoughts?
>

I would hate being forced to use contract qualifiers in every call.  I would love for them to be optional.  That is what Russell proposed.

There could be a compiler switch to decide between mandatory/optional, but optional should be the default.  If mandatory enforcement is in effect, "in" should be just as mandatory as the others.

Mark


In article <an476o$1ngp$1@digitaldaemon.com>, chris jones says...
>
>I agree that 'out' and 'inout' should be required in calls for both reasons you sugest.
>
>And I propose the 'in' be droped altogether as it is implicit and hence redunant just as nobody uses 'auto' in C. I would also prefer 'ref' to 'inout', but thats just personal preferance i guese.
>
>chris
>
>
>"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D94BAF6.80803@deming-os.org...
>> I like D's in/out/inout function parameter modifiers.  However, I think that it would be good to allow the caller to add an "in" "out" or "inout" prefix to any or all arguments.  This allows the caller to document, in the code, how the parameter is to be used.  It would be a syntax error to call a function where one of the parameters didn't match the function definition; if you don't specify a prefix, that's ok.
>>
>> This would make the caller's code easier to read, since it would implicitly document which parameters are out or inout parameters.  It would also pick up bugs that might otherwise happen if the interface changed.
>>
>> Not only that, it would make it possible to overload based on the in/out/inout parameter, although I'm not convinced that's really a good idea.
>>
>> BUT I REALLY THINK...
>>
>> That the appropriate prefix should be REQUIRED for any out or inout parameters.  If we go this way, then not having a prefix is the same as explicitly having an "in" prefix.
>>
>> Thoughts?
>>
>
>

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:an53d6$2k4u$1@digitaldaemon.com...
> There could be a compiler switch to decide between mandatory/optional, but optional should be the default.  If mandatory enforcement is in effect,
"in"
> should be just as mandatory as the others.

I'm trying hard to avoid having compiler switches that change the semantics of the language. We have them in C/C++, and they are just unending problems.

The semantics of source code should be in the source code, it should never be necessary to consult the makefile. I feel kinda strongly about this <g>.

In article <an92mj$hlh$2@digitaldaemon.com>, Walter says...
>
>
>"Mark Evans" <Mark_member@pathlink.com> wrote in message news:an53d6$2k4u$1@digitaldaemon.com...
>> There could be a compiler switch to decide between mandatory/optional, but optional should be the default.  If mandatory enforcement is in effect,
>"in"
>> should be just as mandatory as the others.
>
>I'm trying hard to avoid having compiler switches that change the semantics of the language. We have them in C/C++, and they are just unending problems.
>
>The semantics of source code should be in the source code, it should never be necessary to consult the makefile. I feel kinda strongly about this <g>.
>

That's a good point.  Mine is just that the language should be internally consistent.  It breaks consistency to require only two out of three.  To my mind they are either all optional, or all mandatory.  (The compiler switch was just a concept to permit either type of internal consistency to be used by the programmer, but I see your point too.)

Mark

"chris jones" <flak@clara.co.uk> ha scritto nel messaggio news:an476o$1ngp$1@digitaldaemon.com...
>
> I agree that 'out' and 'inout' should be required in calls for both
reasons
> you sugest.
>
> And I propose the 'in' be droped altogether as it is implicit and hence redunant just as nobody uses 'auto' in C.

I partially agree. look:

 int f (in int a, in int b, out int c);  // declaration

// calls

f(x, y, z); // OK, default behaviour: x, y, z are either 'in', 'out' or
'inout'
f(in x, in y, out z); // OK, call matches declaration
f(in x, out y, in z); // error:  call doesn't match declaration
f(x, y, out z); // OK: 'in' assumed for non-'out' and non-'inout' parameters

What do you think?

Ciao