// 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