// Function parameters, sound, clear and clean //

Rick Trelles RTrelles at bellsouth.net
Tue May 4 13:51:57 PDT 2010


(This I posted in
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Function#section2
I add it here so more people could see and comment it.)


I'm new to D. I think D is a great idea, a much needed thing. But I find 
its specs are terribly sketchy. With sketchy specs D can't go anywhere, 
I think.

Here is an attempt of mine to establish sound, clear and clean specs in 
a simple area to start: function parameters.

I read parameters in D could be of sort "in", "out", "ref", "lazy", 
"final", "const", "immutable, and "scope", but I see almost no 
definitions of these.

This is what I get so far:

in  - Function gets value but no access to the external variable 
related to it.

out - Allows update of original external variables but first
  there's an innitial reset of them.

ref - Not explained here. "Tango w/D" says this is like "out"
(access to the original variable) but without changing their 
values before entering the body of the function.

lazy - Apparently this applies only to parameters that are references to 
functions (or to expressions that somehow are packed in a function-like 
manner). It ensures those functions or expressions are executed 
("evaluated") only if, when, and as many times, as the code inside the 
function body requests it.

scope and others - I find no explanations about what will imply to 
qualify a parameter with these.

But OK, I get at least what some of the intentions are.

Question: Can't all the above be achieved just by having the option of 
adding a one-character token (say the semicolon ';') somewhere in the 
parameter list of the function?

The semicolon would divide the list in two zones: first the "input" and 
then the "input-output" zone. If there is no ';', all would be input.

All variables in the input zone would be of the classical "by value" 
type. If an object in this zone is big, the compiler should know not to 
copy it and use a reference to constant (the original variables will 
contribute their values and it won't be possible to change them in the 
function body).

And in the second zone all would be references, with complete access to 
the original variables. If there would be some advantage (I've never had 
need of this) of resetting some of those variables before entering the 
body of the function, then that could be done manually or applying some 
keyword, like "reset" or "init", to the corresponding parameter.

About those "lazy" function-expresion references, that behaviour is just 
what is commonly needed, it should be the default. Maybe an optional 
"run" command could be implemented to be added to the reference *in the 
function calls*, to have it the other way too if desired.

It would look like this:

storclass rettype funcid( inparams ; outparams ){ body }

This seems to me what essentially would be a huge improvement over C/C++ 
and surely over other languages too, in reference to types of function 
parameters.

If there is any serious inconveniences to this way I propose, or 
something that I'm missing, let's talk about it. And come to 
conclusions, and leave it clearly established.

If there are other functionalities in this area that are worth while, 
someone should describe and justify them *clearly and completely*. So 
other additions could be eventually incorporated and then they would 
also be *clearly established*.

I repeat, with sketchy specs D can't really move ahead. I think.


Rick
I hate typing,
love clearest, simplest powerful structures.


More information about the Digitalmars-d mailing list