On 02/03/12 00:20, Jonathan M Davis wrote: > in is pointless on value types. All it does is make the function parameter > const, which really doesn't do much for you, and in some instances, is really > annoying. Personally, I see no point in using in unless the parameter is a > reference type, and even then, it's often a bad idea with reference types, > because in is really const scope, and the scope is problematic if you want to > return anything from that variable. It's particularly problematic with > arrays, > since it's frequently desirable to return slices of them, and scope (and > therefore in) would prevent that. It's useful in some instances (particularly > with delegates), but I'd use in _very_ sparingly. It's almost always more > trouble than it's worth IMHO.
BTW, scope should have been the default for *all* reference type function arguments, with an explicit modifier, say "esc", required to let the thing escape. It's an all-or-nothing thing, just like immutable strings - not using it everywhere is painful, but once you switch everything over you get the benefits. If it isn't obvious why - GC. The compiler can optimize the cases where it knows a newly allocated object can't escape and reduce or omit the GC overhead. And yes, it can also do this automatically - but that requires analyzing the whole call chain, which is a) not always possible and b) much more expensive. artur
