Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Wendell Adriel]

> For `array` why not just use `list`?
>
> Robert Landers
> Software Engineer
> Utrecht NL

Hey Robert, IDK if I fully understood, but the idea when having the need to
define arrays that are not associative is to use only array instead.
The example I put was to show how something like array is going to
be interpreted behind the scenes.

*---*
*Best Regards,*
*Wendell Adriel.*
*Software Engineer **| Investor | Amateur Photographer | Musician | INFP*
*https://wendelladriel.com *

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Robert Landers]

On Wed, Feb 8, 2023 at 6:23 PM Wendell Adriel
 wrote:
>
> Hello everyone.
> I created the Draft for this RFC:
> https://wiki.php.net/rfc/local_variable_types
> I'd love to hear your thoughts on this before proceeding further.
> If anything should be changed or updated just let me know.
> I'll be happy to help with anything related to this.
>
> *---*
> *Best Regards,*
> *Wendell Adriel.*
> *Software Engineer **| Investor | Amateur Photographer | Musician | INFP*
> *https://wendelladriel.com *
>
>
> Em qua., 8 de fev. de 2023 às 15:54, Alexandru Pătrănescu <
> dreal...@gmail.com> escreveu:
>
> > On Tue, Feb 7, 2023 at 10:21 PM Mark Baker  wrote:
> >
> > > On 07/02/2023 20:53, Olle Härstedt wrote:
> > > > 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 _int(int $value) {
> > static $references = [];
> >
> > $valueWrapper = new class(5) {
> > public function __construct(public int $value) {
> > }
> > };
> > $references[] = $valueWrapper;
> >
> > return $valueWrapper->value;
> > }
> >
> > $intVariable = _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
> >

For `array` why not just use `list`?

Robert Landers
Software Engineer
Utrecht NL

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Wendell Adriel]

Hello everyone.
I created the Draft for this RFC:
https://wiki.php.net/rfc/local_variable_types
I'd love to hear your thoughts on this before proceeding further.
If anything should be changed or updated just let me know.
I'll be happy to help with anything related to this.

*---*
*Best Regards,*
*Wendell Adriel.*
*Software Engineer **| Investor | Amateur Photographer | Musician | INFP*
*https://wendelladriel.com *


Em qua., 8 de fev. de 2023 às 15:54, Alexandru Pătrănescu <
dreal...@gmail.com> escreveu:

> On Tue, Feb 7, 2023 at 10:21 PM Mark Baker  wrote:
>
> > On 07/02/2023 20:53, Olle Härstedt wrote:
> > > 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 _int(int $value) {
> static $references = [];
>
> $valueWrapper = new class(5) {
> public function __construct(public int $value) {
> }
> };
> $references[] = $valueWrapper;
>
> return $valueWrapper->value;
> }
>
> $intVariable = _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
>

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Alexandru Pătrănescu]

On Tue, Feb 7, 2023 at 10:21 PM Mark Baker  wrote:

> On 07/02/2023 20:53, Olle Härstedt wrote:
> > 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 _int(int $value) {
static $references = [];

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

return $valueWrapper->value;
}

$intVariable = _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

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Wendell Adriel]

Hey everyone, it's me, Wendell (that proposed this RFC in the first place).
I'm just using another e-mail because my other email m...@wendelladriel.com
is having some issues with the PHP email lists.

First of all, thanks for all the feedback so far on this proposal.
I'm seeing that the implementation would be far more complex than I thought
it would be.
I have two questions about this:

1. Should I move forward on creating the RFC for further discussion? If so,
I know that I need karma for that, I already created my Wiki account with
the email wendelladriel...@gmail.com and username wendell_adriel. In the
how-to guide says that I need to ask in this list for the needed Karma, so
if you think that I should move on with this RFC can someone give me the
needed karma for that?

2. It would be great to have someone else aboard with more experience in
the PHP source code and the RFC process since I'm a beginner and this seems
to be way more complex than I first thought. Is there anyone that wants to
work with me on the RFC proposal and the implementation if this should
proceed?

Thanks in advance.
Have an amazing day everyone.

*---*
*Best Regards,*
*Wendell Adriel.*
*Software Engineer **| Investor | Amateur Photographer | Musician | INFP*
*https://wendelladriel.com *


Em qua., 8 de fev. de 2023 às 14:40, Rowan Tommins 
escreveu:

> On Wed, 8 Feb 2023 at 00:13, Sergii Shymko  wrote:
>
> > 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 $strings) {
> > ...
> > }
> > array $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; 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 $strings) {
> ...
> }
> function filter_non_strings(array $items): array {
> ...
> }
> array $mixed_list = ['John', 42, 'Jane'];
> $mixed_list = filter_non_strings($mixed_list);
> // when calling filter_non_strings, we know that the value matches
> array, so can deduce that it matches array as well
> // when assigning the result back to $mixed_list, we know (from the return
> type check) that it matches array, so can deduce that it matches
> array as well
>
> do_something($mixed_list);
> // since the value hasn't changed since it was returned, it still matches
> array, 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 or knowing that it
> matches array
> // as a minimum, we need to assert that after modifying it by reference, it
> still matches array, as required by $mixed_list
> // but do we also still know that it matches array?
>
> 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]
>

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Rowan Tommins]

On Wed, 8 Feb 2023 at 00:13, Sergii Shymko  wrote:

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

do_something($mixed_list);
// since the value hasn't changed since it was returned, it still matches
array, 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 or knowing that it
matches array
// as a minimum, we need to assert that after modifying it by reference, it
still matches array, as required by $mixed_list
// but do we also still know that it matches array?

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]

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Sergii Shymko]

From: Olle Härstedt 
Sent: Tuesday, February 7, 2023 11:53 AM
To: Rowan Tommins 
Cc: PHP Internals 
Subject: Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

2023-02-07 17:21 GMT+01:00, Rowan Tommins :
> On 07/02/2023 14:07, Olle Härstedt wrote:
>> It should perhaps be mentioned that analyzers can use type annotations
>> during their process, instead of the more clunky /** @var string */ or
>> similar you have to use today for local variables.
>
> This sounds like you're reaching for Python's approach, where the
> language "supports" the type annotation syntax, but doesn't actually do
> anything with it.

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.

Olle

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php


Hi,

Wanted to add my two cents on potential usefulness of typed variables.

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 $strings) {
...
}
array $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

(I'm a recent mailing list subscriber and have no RFC voting rights whatsoever).
+1 to the proposal as it would nicely complete the type system of PHP.
It's pretty odd to have typed arguments and properties, but not variables.
Moving one step closer to retiring PHPDocs for good is very good as well.

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Mark Baker]

On 07/02/2023 20:53, Olle Härstedt wrote:

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.



$mystring = 'I love elephants';
$findme   = 'php';
int $pos = strpos($mystring, $findme); // $pos can be an integer or false


or when a type can legitimately change


int $result = PHP_MAX_INT;

++$i; // $i is now a float



--
Mark Baker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Olle Härstedt]

2023-02-07 17:21 GMT+01:00, Rowan Tommins :
> On 07/02/2023 14:07, Olle Härstedt wrote:
>> It should perhaps be mentioned that analyzers can use type annotations
>> during their process, instead of the more clunky /** @var string */ or
>> similar you have to use today for local variables.
>
> This sounds like you're reaching for Python's approach, where the
> language "supports" the type annotation syntax, but doesn't actually do
> anything with it.

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.

Olle

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Rowan Tommins]

On 07/02/2023 14:07, Olle Härstedt wrote:

It should perhaps be mentioned that analyzers can use type annotations
during their process, instead of the more clunky /** @var string */ or
similar you have to use today for local variables.



This sounds like you're reaching for Python's approach, where the 
language "supports" the type annotation syntax, but doesn't actually do 
anything with it. I explained in another thread why I think that is a 
poor compromise, because it's unclear whether you can actually trust the 
annotations.


The current "clunky" syntax is clearly a comment as far as the language 
itself is concerned, so there is no expectation when reading it that it 
will have a meaning to plain PHP.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Rowan Tommins]

On 06/02/2023 21:15, someniatko wrote:

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.



I'm not convinced the distinction between "compiled" and "interpreted" 
languages is actually meaningful for modern language implementations - 
PHP does have a compilation step, and even performs some of its 
correctness checks at that stage.


Much more important is the distinction between "static typing" and 
"dynamic typing". The aim of a static typing system is to *prove*, in 
the mathematical sense, that the program is correct according to the 
type system of the language, without executing any of the code. The aim 
of a "dynamic typing" system is instead to *detect* problems in a 
program, while it is running, and to select operations overloaded based 
on the actual type of data.


PHP itself currently only includes dynamic typing features - 
effectively, all the type keywords you add to the source code translate 
to run-time assertions that check the type of data at specific points. 
Mostly, that's currently at function boundaries (parameter and return 
type checking), though typed properties are more complex (especially 
when you access one by reference, and get a "typed reference").


One of the big implications of that is performance: adding checks in 
more places (e.g. on every assignment to a local variable), or more 
complex checks (e.g. checking every element of an array), means that the 
actual program runs slower. It may be possible to implement checks in a 
more efficient way, but it's not going to be a simple patch.


That's why including an official static analyser is tempting, but it's 
not obvious where that would fit in the project and ecosystem (see the 
recent thread on that topic).


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Wendell Adriel]

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 + Hans Henrik Bergan 
 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  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 
 
-- 
PHP Internals - PHP Runtime Development Mailing List 
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[Hans Henrik Bergan]

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  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC Proposal - Types for Inline Variables

[someniatko]

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

[PHP-DEV] RFC Proposal - Types for Inline Variables

[Wendell Adriel]

Hello everyone.

My name is Wendell Adriel, I work with PHP since 2009 and these last couple of 
days I was thinking that we have made HUGE progress with types on PHP so far.

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



The Idea



I was talking about this on Twitter with some developers and I wanted to check 
how's the feeling on this.

I know that there's a draft RFC that mentions this in the Future Scope section: 
https://wiki.php.net/rfc/declare_vars

But my idea is not to have the declaration of variables like that. I'm thinking 
on a straightforward implementation that would be like:



Today we have:



$value = 10;

$value = 'foo'; // OK



My proposal is to be able to do something like:



int $value = 10;

$value = 'foo'; // TypeError



This typing would be optional and under the hood all current declarations would 
implicitly add the mixed type to the variable.

So this:



$value = 10;



Would be interpreted as:



mixed $value = 10;



-



Implementation



I'm new to the PHP source code, but I'm looking into it and studying so I can 
be able to work on the implementation and not only in creating/proposing the 
RFC.

If someone that has more experience wants to help me it would be great.



-



I'm happy to help with anything needed for this to happen and if someone wants 
to discuss further just ping me.

Thanks in advance for the attention.



---

Best Regards,

Wendell Adriel.

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


https://wendelladriel.com