VIP: Inlineable functions

[charles-cooper]

Simple Summary

Allow functions to be inlined

Motivation

Private functions are expensive because of frame switching. Allowing functions to be inlineable allows us to skip that overhead.

Specification

Add a decorator @inline which allows the user to force a function to be inlined. (In the future, the compiler could theoretically use heuristics to decide whether or not to inline a function but that is out of this scope). @inline is only compatible with @private functions. When the compiler sees that it should inline the code but with new variable names and so forth.

(Note: parameters should either not be writeable or pass-by-copy)

example:

@private
@inline 
def priv():
  x: uint256 = 1
  return x + 2
@public
def foo():
  return self.priv() + 3

should have roughly the same output as

@public
def foo():
  priv_x: uint256 = 1
  return (priv_x + 2) + 3

Backwards Compatibility

No incompatibilities

Dependencies

No known dependencies

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

The name-mangling on private variables should make it not possible to write a variable in the enclosing function that would override that behavior.

Otherwise, all for this. Our private functions suck.

[jacqueswww]

This is a good idea, to be fair: @fubuloubu Our private functions are efficient in certain cases where inline functions ones wouldn't be again. Also inline increases bytecode very quickly.

The cool thing about this is that the base for this functionality already occurs in sqrt ;)

[charles-cooper]

this is added in #4481

cf. also #4478 which performs automatic inlining. so i'm not sure we actually need user-tunable inlines anymore -- we should wait 1-2 release cycles for user feedback.