[boost] in/out parameters, coding styles and maintenance [was: class proposal]

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2003-04-24 16:42:55

It seems we've stirred up a little discussion here under the
inauspicious subject of class proposal, and I wanted to add my 2
cents.  In summary, the original poster was frustrated by the
anonymity of passing parameters as non-const references.  He then
proposed a wrapper class that a library writer could use instead of
pass-by-reference which would make code calling the library very
clear as to which paramters were in parameters and which were out
parameters.  From there, we were diverted off into discussions on the
use of const, clarifying what Justin was going after, talk about
using tuples for return values, and talk about potentially inept
coworkers.  I would like to bring the discussion back to a couple of
points I find more relevant to boost (interesting discussion though
it may be):

1) We normally pay a lot of attention to safety of usage, clarity of
intent, confusion from subtle semantics etc in our discussions. 
Sometimes we might even belabour the point (though I think it's
healthy).  This question goes to the library writers here.  Would you
replace:

int foo(int &param);

with

int foo(in_out_param<int> param);

provided that the in_out_param had no space/time overhead.  Actually,
the only proposed benefit is to force the usage of foo from

void MyFunc(int height)
{
    cout << height << endl;
    foo(height);
    cout << height << endl;  // Hey!? What happened?
}

to

void MyFunc(int height)
{
    cout << height << endl;
    foo(in_out_param(height));
    cout << height << endl;  // Ok, height changed as expected.
}

Of course, some library users will find the requirement to wrap up
their parameters irritating.  Additionally, if it's not a widespread
idiom, it could be confusing to people unfamiliar with it.

2) Is this usage going to be so idiomatic that it should be left up
individuals to decide what they want to do with it?  Is it along the
lines coding guidelines that some companies have?  Some places I have
worked, we had exotic iterator adapters and other utility classes. 
Would this just be like that?  Unless I'm missing something, it
shouldn't be too hard to implement.

3) On the other hand, since a major goal of such a utility is to be
ubiquitous and unobtrusive, is it something that we should hash out
"good" syntax for and shine a light on all the quirky corner cases?

On the surface, the idea does not seem unreasonable to me.  But the
proposed usage syntax for library user feels a little heavy handed. 
Lastly, if the proposed implementation has been posted, I missed it,
so can somebody post it or a link again?  Thanks-

Augustus

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com