On 03-02-2012 11:08, Artur Skawina wrote:
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
It is not that simple.
If the class's constructor passes 'this' off to some arbitrary code,
this optimization breaks completely. You would need whole-program
analysis to have the slightest hope of doing this optimization correctly.
--
- Alex
