http://d.puremagic.com/issues/show_bug.cgi?id=6442
--- Comment #16 from Jonathan M Davis <[email protected]> 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 out. 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
