On 03-02-2012 11:41, Artur Skawina wrote:
On 02/03/12 11:21, Alex Rønne Petersen wrote:
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.
It's about enabling the optimization for as much code as possible. And probably
the most interesting cases are strings/arrays - the GC overhead can be huge if
you do a lot of concatenation etc.
Would marking the ctor as "scope" (similarly to "const" or "pure") work for your
case? (it is reasonable to expect that the compiler checks this by itself; it's
per-type, so not nearly as expensive as analyzing the flow)
artur
Well, you would have to mark methods as scope too, as they could be
passing off 'this' as well.
It's probably doable that way, but explicit annotations kind of suck. :(
--
- Alex
