To the first question: i don't believe anyone has ever asked it to be
pulled? I didn't even know about that repo until you pointed it out.
This comes up every once in a while, but our
position has been that 'inline' annotations are silly. In shared code,
why does the declaration get to decide whether the function is inlined
for all call sites?
b.par(b.flat(b.seq(b.ref(expr1), b.ref(op0), b.ref(expr0)), function (a, b, c) {...}), b.ref(expr1))
re: ' inline functions unconditionally': out of curiosity, are there
any C/C++ compilers at all that guarantee 'unconditional inlining'?
Inlining/expansion is something that should be determined and dealt with by a compiler or virtual machine. Having annotations or keywords in source code that attempt to force inlining is completely unnecessary.Just my opinion of course :-)
--
---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/6bf1e0ae-0788-4f59-8dd5-4577c672d247%40googlegroups.com.
Can you provide an provide a code sample for code that doesn't get inlined? If it never gets inlined now it may be that the compiler couldn't inline it even if you told it to ALWAY inline (it doesn't know for sure what the definition is, the method contains expressions that it doesn't know how to rewrite (like recursion)). It maybe that a small change in how you write your code would be sufficient.
On Tue, Jun 17, 2014 at 10:23 AM, Si Robertson <retrom...@gmail.com> wrote:
Inlining/expansion is something that should be determined and dealt with by a compiler or virtual machine. Having annotations or keywords in source code that attempt to force inlining is completely unnecessary.Just my opinion of course :-)
--
---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/ad64d12c-d65b-472d-8011-df275a9c65af%40googlegroups.com.
--
---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/b74283d6-582f-4e15-8025-bcc400d5bad4%40googlegroups.com.