"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ani6po$1gr4$1@digitaldaemon.com...
> Consistency is more important than a few keystrokes.  Contract qualifiers document the code; 'in' should be just as mandatory (or just as optional)
as the
> other two.

'in' should either be droped or mandatory (do you ever use 'auto' in your c
code?)


Mike.

Mandatory then.  C does not pretend to be self-documenting or contract-based, so the analogy with 'auto' is a broken one <g>.  Read the IMP posting about the semantic problem in C regarding 'static'.  When the language itself is inconsistent, you can't blame me for using it asymetrically.

C should be taken as a model for any language and D should do everything it can to repair its many problems.

- Mark

In article <ani8iq$1j9q$1@digitaldaemon.com>, Mike Wynn says...
>
>'in' should either be droped or mandatory (do you ever use 'auto' in your c
>code?)

(Typo, that was "C should NOT be taken as a model for any language..."

Mark)

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ani6po$1gr4$1@digitaldaemon.com...
> Consistency is more important than a few keystrokes.  Contract qualifiers document the code; 'in' should be just as mandatory (or just as optional)
as the
> other two.

Im not sugesting 'in' should be optional and the others mandatory but that 'in' should not exist at all and out/inout mandatory.

The fact that in is not specified can only mean one thing, that it is an 'in' parameter, therefore the omision of 'in' is just as specific as the inclusion of it. There is no question of consistency with this and hence no need to document it. Can you imagine a situation where sombody might be confused over this? I cant even imagine newbies finding it confusing.

> Many languages have confused the issue of call-by-value and
call-by-reference.
> This situation makes 'ref' a bad term.  A better term is 'shared.' The
parameter
> is shared between caller and callee.
>
> The term 'inout' is unhelpful.  It doesn't communicate what is actually happening.  Something goes in, and something comes out, but 'inout' fails
to
> indicate that they are actually the *same* thing.

Thats a very good point.

chris

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:anhq2l$12k2$1@digitaldaemon.com...
> if two threads have a reference to an array, one modifies the array, will the other ALWAYS see the modifications or will it possibly see the old
array
> ?

It'll always see the modifications.

"chris jones" <flak@clara.co.uk> wrote in message news:ani3ss$1djm$1@digitaldaemon.com...
> I also prefer 'ref' to inout, also i would like to so 'in' dropped as
nobody
> is ever going to use it, it is implicit and hence redundant. Its a waste
of
> ascii.

That's probably a good idea.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> Consider passing a value as "inout" parameter to a function.
> Then both the caller and the called functions continue to use the same
> value, by multithreading.
> Now when will the changes of the inout parameter be incorporated into the
> original variable?
> Immediately, or when the called function returns?
> The specification does not tell. (Walter: please put it in)
> The "inout" name suggests the later, but the first happens (i hope).
> Therefore the name "inout" is not really intuitive. I would rather suggest
> "ref", because what is happening is passing a parameter by reference.

inout is also used by IDL, and so is familiar to many C/C++ programmers.

>The fact that in is not specified can only mean one thing

No, it can mean whatever the programmer's previous language experience (or lack thereof) might suggest.

Considering that 'in' need be written in only one place -- the function definition -- I don't think it's too much to ask for consistency's sake. Especially since we want D programmers to think in terms of contracts.

Glad that you liked the 'shared' idea ;-).

Mark

I agree with both points.  Ref makes more sense and it's the term that most people are used to for the concept.  In is just a waste, adds bloat but no clarity.  Makes a good default.  Perhaps we can reuse the "return" keyword instead of adding a new one "out".

Probably too late to worry about this one, alot of people are probably attached to the in/out/inout scheme.  What D has now isn't really broken.

Sean

"chris jones" <flak@clara.co.uk> wrote in message news:ani3ss$1djm$1@digitaldaemon.com...
> I also prefer 'ref' to inout, also i would like to so 'in' dropped as
nobody
> is ever going to use it, it is implicit and hence redundant. Its a waste
of
> ascii.
>
> chris

Some days I write more function declarations than actual code.  Prototyping. So making function declarations more wordy will just hinder people.  In is not necessary.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:anirhi$26cj$1@digitaldaemon.com...
> >The fact that in is not specified can only mean one thing
>
> No, it can mean whatever the programmer's previous language experience (or
lack
> thereof) might suggest.
>
> Considering that 'in' need be written in only one place -- the function definition -- I don't think it's too much to ask for consistency's sake. Especially since we want D programmers to think in terms of contracts.
>
> Glad that you liked the 'shared' idea ;-).
>
> Mark