Description:
------------
This is a feature request. Alas, I lack the competence to implement it myself.

The request is to basically make initially dangerous eval() really usable to i.e. easily create user expression parsers, without requiring pre-parsing of expression in order to check it.

The idea is to pass additional structure to eval() that specifies explicitly allowed variables of the current scope, functions and classes for the expression - disallowing everything else.

I.e. eval($expr, $limits = null) where $limits contains ['variables' => [...], 'functions' => [...], 'classes' => [...], 'operators' => [...], 'statements' => [...]], each option being defaulted to none (null). The default value of $limits = null provides backwards compatibility (everything is allowed).

Potential usage:

$userInput = '2+2*2'
$result = $eval('return '.$userInput.';', ['operators' => [EVAL_EXPRESSIONS], 'statements' => 'return']]);

will produce 6 as expected. 

If the user input contains something disallowed, like '2+my_func(2*2)', it should throw some exception indicating expression is invalid. But passing 'functions' => ['my_func'] in second argument can allow my_func (i.e. mathematical functions like abs, exp, etc.) to work in the user expressions.

The only remaining danger would be the invalid type returned like array instead of integer, etc., but this would be much easier to post-check.

The things to think on is operator and statement allowance. I know this is complex, but it may be a very handy addition to allow users to provide expressions from interfaces without much extra hassle.