Closed YellowAfterlife closed 5 years ago
inline is not currently used in expression syntax at all
That is not entirely true because inline function
exists at expression level. However, that does not cause any grammar problems.
I'm very much in favor of this. My biggest concern is the required AST change.
Can AST be parsed with a metadata ? "inline expr" would be equivalent of "@:inline expr" , and we could have the same of "inline function foo()" actually.
We could do that, but I think with a major version change we should do it properly and add EInline, similar to EUntyped.
An argument against using metadata is that metadata affects the context of the expression typing:
@:inline call1(call2())
This would cause both calls to be inlined because @:inline
is "in context" while typing them.
In that respect, inline call1()
is more similar to cast call1()
and should thus get its own AST node.
We would only allow inlining of @:inline ECall
, not add "inline" meta to whole expression typing as we do for normal metadata.
One remark: I think we should forbid overriding of a method that was force-inlined, just like it's done for normal inline
methods, as inline
should not change semantics and it can be very confusing if the overriden method isn't called because it was force-inlined as the base class method. Implementation-wise this would require marking force-inlined methods and checking for overrides in a separate compiler pass.
Other than that, I have no problem with this proposal 👍
I agree with that.
Allow requesting a function to be inlined at call location
Rendered version