"in" and argument passing (was Re: Destructors, const structs, and opEquals)

[spir]

On Sat, 4 Dec 2010 09:00:05 +0000 (UTC)
Franciszek Czekala <home at valentimex.com> wrote:

> Anyway, if struct has value semantics then perhaps the argument to
> opEquals should have simply 'in' mode? In Ada95 the 'in' mode of
> the arguments does not determine how the arguments are passed
> internally to the function. The compiler can choose to pass them
> by value or by reference as suitable. Since the 'in' mode makes
> the arguments constant inside, it does not really matter how the
> arguments are passed, so why burden the user with this knowledge?

I support this point of view. In general, I think properly chosen qualifiers should have clear semantics (meaning); then, the language internally may adopt what is best for simplicity, efficiency, etc... as long as semantics are maintained. A programmer should not have to care about it (what is wrong for instance about arrays). Semantics and implementation may be much more kept apart in D. What is the sense of "in" for an app designer?

For the case of "in" (with a value argument), as the argument does not need to be protected by copy since it is known not to change, the compiler may chose to pass it by ref when more efficient (structs, mostly). Moreover, why not have "in" be the default for values? What is the meaning of changing a value parameter? 
	draw (shape, color, position);
What is the sense of changing color or position? Qualifiers (semantics in general) could make more sense.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com