On 02/03/12 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)
Actually, passing 'this' to some "some arbitrary code" isn't a problem, unless the code in question has the "esc" annotation, in which case you need to mark the ctor (or any other method) as "esq" too; that will turn off the optimization, for this struct/class, obviously. That's why "scope" needs to be the default - mixing it with code that does not guarantee that the object does not escape does not really work - you cannot call anything not marked with "scope" with an already scoped object. Which means you need to mark practically every function argument as scope - this doesn't scale well. artur
