This minor D topic is getting more press than it deserves, however my comments may elucidate some philosophical issues that will help in many other areas.


1a. Talk to more software managers and functional specification people in the
corporate and military worlds.  They are not fond of "implicit" things that "you
are just supposed to know."  I would not be surprised if they used
commented '/*in*/' everywhere.

1b. Minimum-ascii thinking led to the horrible C syntax and butchered semantics that we have today.  Remember when you were first learning C?  I do.  It was awful.  Everything was so cryptic.

2. Talk to non-C programmers and novices.  They will give you all kinds of weird ideas about call-by-reference and call-by-value.  Maybe D will never be used by non-C programmers, but I sure hope it will.

3. Recent posts suggest special cases in D (array objects) where call-by-value is not the default.  So now what you are "just supposed to know" starts encompassing various special cases for your memorization pleasure.

4. I dislike 'ref' because it might as well just be '&'.  The in/out stuff is about contracts, and C has no such concept.  D should use a word that has something to do with contracts -- and conversely, there should be *no* direct translation into any C keyword or concept.  I'll take 'inout' over 'ref' any day.  Be consistent.  If we use 'ref', then we are now using a term that describes the technical implementation, not the contract.  So logically it follows that 'in' should become 'pushed-stack' and 'out' should become 'popped-stack'. Yuk!

Mark


In article <anj7bn$2hvt$1@digitaldaemon.com>, Sean L. Palmer says...
>
>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
>
>

Lots of great comments! Here are some of mine:

1) IDL already uses in, out, and inout. I've seen many people use /*in*/, etc.

2) Many D type are implicitly passed by reference not by value (such as
class objects). Having a 'ref' keyword may thoroughly confuse the issue.

3) Having 'inout' to me means that a value is passed in, and then possibly modified by the function.

4) I wished to abandon the C++ & reference notation, because it was used for
3 different purposes:
    a) runtime efficiency
    b) to initialized the caller variable
    c) to reset the caller variable
To know which it is, you have to consult the documentation which is always
wrong, ambiguous, or missing.

5) In D, the distinctions between a, b, c are clear (or at least clear enough that an extra IDL layer is not needed). The whole existence of IDL is to cover a basic failing of C++.

6) Sure the 'in' is redundant - but some redundancy is good for reducing typo errors. 'in' is there for the (many) programmers who like to use /*in*/ and would like some language support for their style. 'in' is optional (I don't use it myself), and is harmless enough if you don't want to use it.

I just don't want 'in' becoming mandatory.  ;)

Sean

"Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...

> 6) Sure the 'in' is redundant - but some redundancy is good for reducing
> typo errors. 'in' is there for the (many) programmers who like to use
/*in*/
> and would like some language support for their style. 'in' is optional (I don't use it myself), and is harmless enough if you don't want to use it.

in C/C++ you have to write all function defs twice (one in .h one in .cpp), in D its only once, so you've saved all those chars, is a few in's realy that much more typing.


"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anj7mk$2ibr$1@digitaldaemon.com...
> 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
>
>

Don't worry, I won't do that <g>. Requiring it would mean that 'in's would become as ubiquitous as 'const' in C++ parameter lists, and would be just as distracting (to me, anyway).

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ankih8$uhi$1@digitaldaemon.com...
> I just don't want 'in' becoming mandatory.  ;)
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...
>
> > 6) Sure the 'in' is redundant - but some redundancy is good for reducing
> > typo errors. 'in' is there for the (many) programmers who like to use
> /*in*/
> > and would like some language support for their style. 'in' is optional
(I
> > don't use it myself), and is harmless enough if you don't want to use
it.
>
>

Yes.

I just won all those chars back from C++, do you think I'm just going to give them away that easily? ;)

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:ankl33$118o$1@digitaldaemon.com...
> in C/C++ you have to write all function defs twice (one in .h one in
.cpp),
> in D its only once, so you've saved all those chars, is a few in's realy that much more typing.
>
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anj7mk$2ibr$1@digitaldaemon.com...
> > 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
> >
> >
>
>

Maybe parameters should never be writable, unless you explicitly say it should be.  Disallow writes to in parameters even inside the function.  Then by default it's reference, except for small types.  And if the callee wants to modify it he must do the copy (or cast) client-side.  And callers can rest assured the parameters they're sending are sort of guaranteed (barring casts) not to allow callees to alter their "in" parameters.  Certainly this would be a great boon to compiler optimization.

in other words I want to make this illegal:

uint strlen(char* s)
{
    // uint len=0; while (*s++) ++len; return len;  // error... can't modify
parameter "s"
    uint len=0; char* scan = s; while (*scan++) ++len; return len; } // ok
}

void zero(char* s)
{
    *s = 0;  // this is ok, writing thru pointer parameter.
}

Writing to out parameters should be ok.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ankrnc$18pl$2@digitaldaemon.com...
> Don't worry, I won't do that <g>. Requiring it would mean that 'in's would become as ubiquitous as 'const' in C++ parameter lists, and would be just
as
> distracting (to me, anyway).
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ankih8$uhi$1@digitaldaemon.com...
> > I just don't want 'in' becoming mandatory.  ;)
> >
> > Sean
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...
> >
> > > 6) Sure the 'in' is redundant - but some redundancy is good for
reducing
> > > typo errors. 'in' is there for the (many) programmers who like to use
> > /*in*/
> > > and would like some language support for their style. 'in' is optional
> (I
> > > don't use it myself), and is harmless enough if you don't want to use
> it.
> >
> >
>
>

If the parameter is call by reference, like a class object, then even if the function copies the parameter to a local so he can modify it, he still will be modifying the referred to type. I don't understand the advantage here.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anm3km$2g7p$1@digitaldaemon.com...
> Maybe parameters should never be writable, unless you explicitly say it should be.  Disallow writes to in parameters even inside the function.
Then
> by default it's reference, except for small types.  And if the callee
wants
> to modify it he must do the copy (or cast) client-side.  And callers can rest assured the parameters they're sending are sort of guaranteed
(barring
> casts) not to allow callees to alter their "in" parameters.  Certainly
this
> would be a great boon to compiler optimization.
>
> in other words I want to make this illegal:
>
> uint strlen(char* s)
> {
>     // uint len=0; while (*s++) ++len; return len;  // error... can't
modify
> parameter "s"
>     uint len=0; char* scan = s; while (*scan++) ++len; return len; } // ok
> }
>
> void zero(char* s)
> {
>     *s = 0;  // this is ok, writing thru pointer parameter.
> }
>
> Writing to out parameters should be ok.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:ankrnc$18pl$2@digitaldaemon.com...
> > Don't worry, I won't do that <g>. Requiring it would mean that 'in's
would
> > become as ubiquitous as 'const' in C++ parameter lists, and would be
just
> as
> > distracting (to me, anyway).
> >
> > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ankih8$uhi$1@digitaldaemon.com...
> > > I just don't want 'in' becoming mandatory.  ;)
> > >
> > > Sean
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...
> > >
> > > > 6) Sure the 'in' is redundant - but some redundancy is good for
> reducing
> > > > typo errors. 'in' is there for the (many) programmers who like to
use
> > > /*in*/
> > > > and would like some language support for their style. 'in' is
optional
> > (I
> > > > don't use it myself), and is harmless enough if you don't want to
use
> > it.
> > >
> > >
> >
> >
>
>

It means the compiler can safely decide whether to pass by reference or by value based only upon performance considerations (for in parameters) since the callee is "guaranteed" not to alter it.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ann6h0$1c57$2@digitaldaemon.com...
> If the parameter is call by reference, like a class object, then even if
the
> function copies the parameter to a local so he can modify it, he still
will
> be modifying the referred to type. I don't understand the advantage here.
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:anm3km$2g7p$1@digitaldaemon.com...
> > Maybe parameters should never be writable, unless you explicitly say it should be.  Disallow writes to in parameters even inside the function.
> Then
> > by default it's reference, except for small types.  And if the callee
> wants
> > to modify it he must do the copy (or cast) client-side.  And callers can rest assured the parameters they're sending are sort of guaranteed
> (barring
> > casts) not to allow callees to alter their "in" parameters.  Certainly
> this
> > would be a great boon to compiler optimization.
> >
> > in other words I want to make this illegal:
> >
> > uint strlen(char* s)
> > {
> >     // uint len=0; while (*s++) ++len; return len;  // error... can't
> modify
> > parameter "s"
> >     uint len=0; char* scan = s; while (*scan++) ++len; return len; } //
ok
> > }
> >
> > void zero(char* s)
> > {
> >     *s = 0;  // this is ok, writing thru pointer parameter.
> > }
> >
> > Writing to out parameters should be ok.
> >
> > Sean
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:ankrnc$18pl$2@digitaldaemon.com...
> > > Don't worry, I won't do that <g>. Requiring it would mean that 'in's
> would
> > > become as ubiquitous as 'const' in C++ parameter lists, and would be
> just
> > as
> > > distracting (to me, anyway).
> > >
> > > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ankih8$uhi$1@digitaldaemon.com...
> > > > I just don't want 'in' becoming mandatory.  ;)
> > > >
> > > > Sean
> > > >
> > > > "Walter" <walter@digitalmars.com> wrote in message news:anjev9$2qq0$1@digitaldaemon.com...
> > > >
> > > > > 6) Sure the 'in' is redundant - but some redundancy is good for
> > reducing
> > > > > typo errors. 'in' is there for the (many) programmers who like to
> use
> > > > /*in*/
> > > > > and would like some language support for their style. 'in' is
> optional
> > > (I
> > > > > don't use it myself), and is harmless enough if you don't want to
> use
> > > it.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Sean L. Palmer wrote:
> Maybe parameters should never be writable, unless you explicitly say it
> should be.  Disallow writes to in parameters even inside the function.  Then
> by default it's reference, except for small types.  And if the callee wants
> to modify it he must do the copy (or cast) client-side.  And callers can
> rest assured the parameters they're sending are sort of guaranteed (barring
> casts) not to allow callees to alter their "in" parameters.  Certainly this
> would be a great boon to compiler optimization.

Use an inout parameter.  It doesn't matter if it's generated on the stack like a return from a function call - our compilers should be getting more savvy about constructing stack objects anyway (stack arrays are the next big thing), and should be able to provide a pointer to them.

Not really an anything to optimisation.  Memory caching is the problem here; the fewer distinct memory scopes in a function the better.  So if the function is complex and the caller isn't passing a pointer to a stack object (say, a class object member), I'd bet it would be faster to pass on the stack.

What could happen is that it could pass a pointer if the parameter is explicitly "in" and if the object is on the stack, but copy it onto the stack if it's coming from elsewhere in memory.  There's no point in testing it in DLI right now due to its sucking.