[RFC DISCUSSION] var_type

Hi Richard,

Hi Dan!

As other noted elsewhere by others, the name of the function is
slightly misleading for this case:

var_type(1 + 1);

However I don't have a better suggestion.

The name comes from Sara from the original typeof() discussion thread. I
understand the arguments of the people but as I already explained on
Reddit, the usage of var_type() on expressions like the above is nothing
anyone would ever do, especially if the TYPE_INT constant is exposed in
userland. One would only use it to get the type of the value that is
currently stored in a variable of which the type is unknown.

vat_type() or value_type() could be good choices as function name.
However, both would introduce new prefixes and I actually do not think
that this is a good idea because it will require people to remember more
and more and more prefixes which makes no sense. It is a declared goal
of this RFC to make is simpler for developers to find what the need
(aided by their IDE and brain). Remembering that you can get additional
information about a variable (its value, type, ...) via the super old
var_* prefix is definitely a good thing, shows visions, and an overall
goal. Note that I plan to provide a var_info() function in my next RFC
that builds upon this.

TL;DR I still like Sara's suggestion and intend to keep it.

From the second half of the RFC:

const TYPE_FALSE = 'false';
const TYPE_TRUE = 'true';

Although as an implementation detail they are present in the engine,
those aren't types in userland. i.e. you can't do

function foo(true $i_only_accept_true) {}

Yes, I also struggled to actually expose them (and write a comment for
them). I searched some code bases and found many usages of literal true
and false, this convinced me that there is a need for them. Introduction
of true and false as type declarations was also discussed and proposed
multiple times (did not make as of yet though).

I am definitely open to removing them again! Should we add a third poll?

--
Richard "Fleshgrinder" Fussenegger