The argument that these would have to be universally used isn't really true.  You could apply out and in_out throughout a project and get the full benefit of its use.  The point here is, if you care to use them, they're nice.  If you don't care to use them, I guess no one is making you, like no one is making anyone use the STL, or any kind of good programming practice.
 
So, I'm not suggesting anyone go out and start ripping up old code to retrofit it.  The idea would be to use it going forward in projects.  Not necessarily inside the boost library, but, it's a nice library for use at the office, or personal projects.  Again, as you start a project, that you know is going to grow to millions of lines of code, and be maintained by countless developers over a number of years, using a library like this throughout the project at the beginning would make long term maintenance much, MUCH easier.
 
----- Original Message -----
From: Glen Knowles
To: 'Joel de Guzman ' ; 'Boost mailing list '
Sent: Thursday, May 01, 2003 11:37 PM
Subject: RE: [boost] in/out parameters, codingstylesandmaintenance

From: Joel de Guzman
>> It doesn't need to be used everywhere in every project.  The point
>> is, if you're starting something new, and you can be fairly sure that
>> it's going to be used for years to come, you can start a project with
>> it.  I'm not suggesting that you use it IN the boost libraries even.
>> I just see it as a useful utility for anyone who would like to use it
>> to keep their own code clear.

>I'll repeat myself: It won't have teeth if it's not enforced. The
>problem is that you can't enforce it. You keep on saying that the goal
>is so that the coder would be saved "the trouble of having to hunt down
>all kinds of functions to find out if and when you can expect your
>variables to change". If it's not applied globally, then the coder will
>be as confused as before. She'll still have to hunt down all function
>calls to find out if and when her variable will be changed or not. The
>case-by-case nature of your solution will cause more confusion, AFAICT.
>When you see:
>
>    foo(a, b, c)
>
>Are you 100% sure, without looking at the docs or the API, that
>a, b or c is not modified? The only plausible answer is: that depends,
>if foo is retrofitted or not. *** That's the problem ***.  Anything less
>than 100% guarantee is false security.

There is merit in what you say, that if you're going to do this the best way to do it is in the language, and I think that's the only thing that would get me to use it. OTOH, you're definitely seeing the glass as half empty. Its true that you can't always know for sure, but there is _some_ value in the fact that if you see:

foo(out(a), b, c)

you _know_ that a is going to be changed.

Glen