www.digitalmars.com         C & C++   DMDScript  

D - Suggestion: Allow (if not require) in/out/inout modifiers on function

reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
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?
Sep 27 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
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?

Sep 27 2002
prev sibling parent reply "chris jones" <flak clara.co.uk> writes:
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?

Sep 28 2002
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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?


Sep 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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,

 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>.
Sep 30 2002
parent Mark Evans <Mark_member pathlink.com> writes:
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,

 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
Oct 01 2002
prev sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"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

 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
Oct 02 2002