RFC Proposal - Types for Inline Variables

Hey, thanks for the feedback Illia and Hans.

Illia, I think that the main motivation for having the support of typing inline variables is that with that we can have more safety in the code.

The code can be more shielded from bugs and easier to maintain.

I don't dislike the idea of having something like const on JS, but I think that adding the support to add types to inline variables at least IMO is a step further on all the typing that was already added in the language.

We have today the ability to add types to function arguments, return and in class properties. So this is just another step towards adding support to optional typing on another place.

Types can bring more confidence when writing code, you can see that for example a lot of people in the JS community is now using TypeScript because of the types.

I love that PHP already added type support to a lot of places and adding the support for typing inline variables would be a game changer for the language I think.

Hans, you sent a good example.

I think that in this case, it should throw a TypeError, yes.

I know this would add a lot of breaking changes.

But if we want to avoid some breaking changes we for example make use of the declare(strict_types=1) to enforce this if this would means in less breaking changes.

Best Regards,

Wendell Adriel.

Software Engineer | Investor | Amateur Photographer | Musician | INFP​

https://wendelladriel.com

---- On Tue, 07 Feb 2023 08:34:07 +0000 Hans Henrik Bergan divinity76@gmail.com wrote ---

function f(int $value){
$value="foo"; // should this be a TypeError? BC break all the things
}

On Mon, 6 Feb 2023 at 22:15, someniatko mailto:someniatko@gmail.com wrote:

Hi there,

I am not a core PHP language developer, just a regular PHP programmer, and
cannot speak for the whole community, so I'll just share my opinion.

I believe a new language feature suggestion should contain not only its
description, but also motivation: i.e. what are we trying to achieve with
it. Will the development experience be worse without it, or maybe it
disallows some sneaky bugs to appear in your code, or maybe it acts as a
native documentation for your code etc.

Personally it's hard for me to see what kind of improvement will
restricting a type of a variable bring. It may prevent repurposing the
variable with the same name for a different use somewhere down the
function, which can lead to bugs if a function is large enough. However,
for such cases I think better idea would be to introduce const variables
like in JavaScript - which can only be set once and cannot be reassigned
later. This way you'll also guarantee the type of the variable will be
preserved.

We can add types in a lot of places, but we still don't have a way to add
types to inline variables.

int $value = 10;
$value = 'foo'; // TypeError

Can you describe some use cases where this feature will be useful? I see
it's coming from statically typed / compiled languages like C++, but in
such languages compiler must know variable type in order to manage memory
properly. As PHP is an interpreted language, it doesn't have this problem.

Regards,
Illia / someniatko

--

To unsubscribe, visit: https://www.php.net/unsub.php

No not really. I'd expect it behave similar to function argument
type-hinting in PHP, that is, runtime checks, but where the notation
can be used by external tools.

The big difference is that the current checking for function arguments
is only necessary when a function is called; but that checking for
local-scoped variables would be required on every assignment to a
variable, or operation that can change a variable value; and that
becomes more problematic with the potential need for union types.

Hi Mark,

I saw that you and Olle were discussing that type checking should be
similar with functions typed parameters .
But in reality, it should be implemented more like typed properties.

Actually that's already possible with something like https://3v4l.org/T6GFS
function &declare_int(int $value) {
static $references = [];

$valueWrapper = new class(5) {
    public function __construct(public int $value) {
    }
};
$references[] = $valueWrapper;

return $valueWrapper->value;

}

$intVariable = &declare_int(0);

$intVariable = 42; // works
$intVariable = 'test'; // fails

Even the PHP_INT_MAX works (it fails).

To give credit, I saw it discussed few years ago on twitter and here you
can see a nice playground implementation: https://github.com/azjezz/typed/
I don't see a bug technical performance downside, other than the wrapper
class references that you need to have a management for.
I think an implementation in C would be not less performant than how
properties types are checked.

Regards,
Alex

I think, typed variables would be a necessary prerequisite for typed
arrays and eventually generics.
If my understanding is correct, the primary concern there is performance
overhead of iterating items for type checking.
With typed variables, type checking is done at assignment and passing
typed array around becomes lightweight.
It would be enough to type check against a known array item type without
iterating over items.

For example:
function do_something(array<string> $strings) {
...
}
array<string> $names = ['John', 'Jane', 'Jake']; // items are type
checked similar to variadic argument unpacking
sort($names);
do_something($names); // lightweight type check as for scalar types

This is probably more complicated to implement than you're imagining.

Firstly, there is a key distinction between variables and values: when
you say do_something($names), the receiving code in do_something doesn't
know that the argument it was given is the variable $names, with type
array<string>; it just receives the value ['John', 'Jane', 'Jake'].

That leads to another distinction: the variable has a single type
constraint ("must always point to a value matching this type"), but the
value has multiple pieces of type information ("has been checked as
meeting these different constraints"). Both can also be deduced using the
relationships between types. For example:

function do_something(array<string> $strings) {
...
}
function filter_non_strings(array<mixed> $items): array<string> {
...
}
array<string|int> $mixed_list = ['John', 42, 'Jane'];
$mixed_list = filter_non_strings($mixed_list);
// when calling filter_non_strings, we know that the value matches
array<string|int>, so can deduce that it matches array<mixed> as well
// when assigning the result back to $mixed_list, we know (from the return
type check) that it matches array<string>, so can deduce that it matches
array<string|int> as well

do_something($mixed_list);
// since the value hasn't changed since it was returned, it still matches
array<string>, even though the variable doesn't have that constraint

sort($mixed_list);
// for this call to succeed, we need to know that the variable is an array;
we can deduce that from knowing it matches array<string> or knowing that it
matches array<string|int>
// as a minimum, we need to assert that after modifying it by reference, it
still matches array<string|int>, as required by $mixed_list
// but do we also still know that it matches array<string>?

It's all probably doable, but I think it's the other way around from your
initial statement: working out how to cache type checks would be a
pre-requisite for implementing local variable types.

Regards,

Rowan Tommins
[IMSoP]