Jérôme M. Berger Wrote:
> bearophile wrote:
> > I have found this page linked from Reddit (click "Toggle all summaries" at
> > the top to read the full page):
> > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
> >
> > At Google C++ isn't the most used language, so it may be better to use a
> > C++ style guide from a firm that uses C++ more than Google. On the other
> > hand Google has hired many good programmers, and probably some of them have
> > strong C++ experience, so if you are interested in C++/D this style guide
> > deserves to be read.
> >
> > This guide is mostly (as it often happens with C++) a list of features that
> > are forbidden, I think usually to reduce the total bug count of the
> > programs. Some of such imposed limits make me a little nervous, so I'd like
> > to remove/relax some of those limits, but I am ignorant regarding C++,
> > while the people that have written this document are expert, so their
> > judgement has weight.
> >
> > They forbid several features that are present in D too. Does it means D has
> > to drop such features (or make them less "natural", so the syntax
> > discourages their use)?
> >
> > Here are few things from that document that I think are somehow
> > interesting. Some of those things may be added to D style guide, or they
> > may even suggest changes in the language itself.
> >
> > -------------------
> >
> >> Function Parameter Ordering: When defining a function, parameter order is:
> >> inputs, then outputs.<
> >
> > D may even enforce this, allowing "out" only after "in" arguments.
> >
> I actually use the inverse convention: "out" arguments come first.
> This way, it is easy to see that "a = b" and "assign (a, b)" modify
> "a" and not "b".
>
> Jerome
Ditto. A special use case to consider is when you have a function template
that returns a type
that is a template parameter and the types of the function arguments are also
template parameters.
Often type inference can be used to determine the type of the function
arguments without explicit
qualification of the argument types in the instantiation. The return type must
be specified however,
since inference cannot be made from missing information.
This suggests a natural order that results (and out arguments) should be on the
LHS and (in) arguments
on the RHS.
So if one writes this:
R Foo(R, A1, A2)( A1 arg1, A2 arg2) {
R r;
return r;
}
auto r = Foo!(double)( 3, 4);
Isn't it more natural or consistent to write this also:
void Bar(R, A1, A2)( out R r, A1 arg1, A2 arg2) {
}
double r;
Bar!(double)( 3, 4);
I haven't tried it so not sure if this works but you get the idea.
Another reason why outs/inouts should be before in arguments is in the case of
functions
taking variable length argument lists or variadic arguments. Normally there is
only one
output argument but there is an arbitrary number of input arguments that the
function
can take.
Yet another reason why so is by analogy with output stream functions; an output
stream
argument is analogous to an output value or reference.
Nearly all I/O libraries that I've seen have usage like this:
fprintf( stdout, /+args...+/);
write( os, value);
Rarely the other way around, namely, input arguments before output stream/file
channel argument.
-- Justin Johansson
