<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sun, May 5, 2013 at 12:38 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, May 4, 2013 at 8:46 AM, Faisal Vali <<a href="mailto:faisalv@gmail.com">faisalv@gmail.com</a>> wrote:<br>

> I just wanted to float this patch out for some feedback - It's not ready for<br>
> commit.<br>
> There is no functionality change - so no tests included.<br>
><br>
> This patch addresses the following:<br>
>   1) It replaces the use of the "__invoke" magic name for the static<br>
> invoker, with a property within<br>
>     the lambda class  - I thought this would be a less brittle approach and<br>
> potentially more efficient<br>
> -   though it takes up more space in the LambdaDefinitionData - how big a<br>
> deal is that?<br>
>       - also with my current change can i just drop the name for this<br>
> function or do i need the<br>
>         "super-secret" name?<br>
<br>
</div>I'm a little confused - it seems all the change is to change the name<br>
"__invoke" to "__$#lambda_invoker" - is there any particular reason to<br>
believe the latter is substantially safer than the former? The<br>
language specification reserves both identifiers for use by the<br>
implementation equally.<br>
<div class="im"><br></div></blockquote><div><br></div><div>The name change is secondary to simply storing the static invoker as a property within the LambdaDefinitionData, which is what I'd really like feedback on.<br>
</div><div>I suppose __invoke is as good a name as any - i thought by making it more cryptic, it might be safer - but really I was hoping we might not need to name this function at all?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
>   2) Also I intend to put some utility functions in Lambda.h (I have<br>
> included some samples - these functions currently might overlap in<br>
> functionality - in my initial generic lambda implementation they were<br>
> scattered amongst various files, and i thought it might be better to<br>
> centralize them a little) - here are my questions:<br>
>      - do you prefer to place utility functions within CXXMethodDecl or Sema<br>
> (ugh - the recompiles<br>
>         suck with changes!) if they make sense there?<br>
>         That is do you prefer IsLambdaCallOperator(MD) or<br>
> MD->IsLambdaCallOperator() ?<br>
<br>
</div>I'm a little confused by this too - there seem to be utility functions<br>
that aren't called/dead-code, though I haven't looked closely.<br></blockquote><div><br><br></div><div>Yeah - except for the first one, they are all dead code as of now - only the first one is relevant to the patch (which i'm hoping to drop).<br>
</div><div>I don't intend to submit those for commit-review just yet.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Could you at least separate out your cleanup changes from the semantic<br>
ones so it's easier to see what's what?<br></blockquote><div><br></div><div>Once I get some direction on which is preferred: storing a pointer to the lambda static invoker within the class (my proposed solution), versus giving it a name and looking it up within the class (status quo) - I will re-submit a patch with just code, relevant to that fix.<br>
<br></div><div>Faisal Vali <br></div></div></div></div>