--- Comment #16 from Jonathan M Davis <> 2011-08-07 00:00:41 
PDT ---
const, immutable, shared etc. have a large effect on the semantics of a
program. The compiler gives you additional guarantees as a result. e.g.
immutable variables can't be altered and non-shared can't be affected by other
threads. Their effects are quite far-reaching. However, the situation with your
feature request is much different.

In the current situation with ref and out, the compiler is aware of what can
and can't be passed by ref, and won't let you pass something by out or ref if
it can't be passed by ref. However, there's no indicator at the call site what
is passed by ref and what isn't (which _can_ cause some confusion). If you were
required to put ref or out at the call site, that confusion would go away. It
wouldn't add any more guarantees to the program whatsoever, since it would have
no effect on the semantics of the program, but it would make it clear to the
programmer whether a particular function was passing by ref or not (such a
feature might or might not be problematic in cases where a function is
overloaded on ref). You're effectively forcing documentation of what is and
isn't being passed by ref. It would also clutter the code somewhat in that
you'd be required to always put ref or out when the function has a ref or out
parameter. Whether the benefit of making it explicitly clear what is and isn't
being passed by ref or out is worth having to type ref or out every time that
an argument is passed by ref is up for debate, and how that interacts with
overloads would have to be examined, but there _is_ a clear benefit with such a
feature in that it's always clear whether an argument is being passed by ref or

However, in your suggestion, ref and out are _not_ required at the call site.
This has the advantage of not breaking any current code and that those who
don't want to use the feature don't have to, but it pretty much negates the
value of the feature as well. You have the guaranteed that if an argument in a
function call is marked with ref or out that it's being passed by ref or out,
but because ref and out are not required at the call site, you don't actually
know _anything_ about whether an argument is passed by ref or not when an
argument isn't marked with ref or out. So, if you're reading code which uses
ref and out on function arguments, you get the false sense of security that
it's making it clear what is and isn't being passed by ref, and there's a good
chance that you're going to think that any arugments which aren't marked with
ref or out are being passed by value, and you're going to misunderstand the
code, which is going to lead to mistakes. So, arguably, the situation would be
_worse_ than it is right now. You really don't get much more out of it than if
you used comments to mark arguments with ref and out. The only benefit that you
get is that it checks your "comments" to make sure that the arguments that
they're next to are actually passed by ref or out like you claim they are.

So, if your feature were _required_, then there would be some definite value in
it. Personally, I don't think that it would be worth the extra clutter in the
code, but other people may disagree (you obviously do). But if it's not
required, then it really doesn't add much more than using comments and is more
likely to lead to mistakes IMHO. So, I don't think that it's at all a good idea
to add this feature to the language.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to