Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.47 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAH0Uv3F6ouDdUFptAca7y9Wob=i4j8okzpdcpWZ17w8abP-ARQ@mail.gmail.com>
References: <CAEUnE0d+rHG-Rvjt7QAN6x6L+BP5Yb_cz8sGuOFDOkx-kCehkA@mail.gmail.com>
 <CANUQDCj=y+owxCzrbwn1XYgy2WCy2sFDTA=HqMkL5nO8xmypjA@mail.gmail.com>
 <CAEUnE0exBYHm4i7hymN7867r6GknuaCvbvTeQ8ViNckg3kTSqw@mail.gmail.com> <CAH0Uv3F6ouDdUFptAca7y9Wob=i4j8okzpdcpWZ17w8abP-ARQ@mail.gmail.com>
Date: Wed, 3 Jan 2018 18:21:23 +0100
Message-ID: <CAH0Uv3GdSB4FOhk7Bo8d2wuMRpD6cdz63GWz3wQ6t7JEHceR_Q@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: Niklas Keller <me@kelunik.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
From: andreas@dqxtech.net (Andreas Hennings)

Another idea I have when reading this proposal is "implicit" typing
based on the initialization.

E.g.

$x = 5;
$x = 'hello';  // -> Error: $x was initialized as integer, and cannot
hold a string.

or

$x = $a + $b;
$x = 'hello';  // -> Error: $x was initialized as number (int|float),
and cannot hold a string.

To me this is only acceptable if the implicit type can be determined
at compile time.
So:

if ($weather_is_nice) {
  $x = 5;
}
else {
  $x = 'hello';  // -> Error: $x would be initialized as int
elsewhere, so cannot be initialized as string.
}


This change would be controversial and leave a lot of questions.
It would be a BC break, unless we introduce yet another declare()
setting, e.g. declare(implicit_types=1).

It could be tricky for global variables, or in combination with
include/require, where the variable can be seen from outside a
function body, and outside the range of the declare() statement.

I only mention it here because it relates to the proposal. I do not
have a strong opinion on it atm.


On 3 January 2018 at 18:10, Andreas Hennings <andreas@dqxtech.net> wrote:
> This proposal contains some interesting ideas, which I see as separate:
> 1. A syntax to declare the type of local variables.
> 2. A syntax to declare the type of object properties.
> 3. Preventing local variables, object properties and parameters to
> change their type after initialization/declaration.
>
> For me the point 3 is the most interesting one.
> I think the other points are already discussed elsewhere in some way,
> although they are clearly related to 3.
>
> Point 3 would be a BC break, if we would introduce it for parameters.
> Current behavior: https://3v4l.org/bjaLQ
>
> Local variables and object properties currently cannot be types, so
> point 3 would not be a BC break for them, if we introduce it together
> with 1 and 2.
> But then we would have an inconsistency between parameters and local
> vars / object properties.
>
> What we could do to avoid BC break is to introduce
> declare(fixed_parameter_types=1) in addition to
> declare(strict_types=1).
> For local variables and object properties, the type would always be fixed.
> But for parameters, it would only be fixed if the
> declare(fixed_parameter_types=1) is active.
>
> Maybe to make it less verbose, we could say declare(strict_types=2),
> which would mean the combination of both those things?
> Or some other type of shortcut.
> I think we will have to think about shortcuts like this if we
> introduce more "modes" in the future.
>
>
>> Currently the var keyword is used to formally declare a variable.
>
> Are you talking about local variables?
> In which PHP version? https://3v4l.org/o0PFg
>
> Afaik, currently var is only used for class/object properties from the
> time when people did not declare the visibility as
> public/protected/private.
>
>
>> If the type is omitted, scalar is assumed.  If Fleshgrinder's scalar RFC is
>> accepted then it would make sense to allow programmers to explicitly
>> declare the variable as a scalar, but in any event when the type is omitted
>> scalar must be assumed for backwards compatibility.
>
> If no type is specified, then "mixed" should be assumed, not "scalar".
> Assuming "scalar" would be a BC break, and it would be confusing.
>
>
> On 3 January 2018 at 10:03, Michael Morris <tendoaki@gmail.com> wrote:
>> On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller <me@kelunik.com> wrote:
>>
>>> Hey Michael,
>>>
>>> I don't think the BC break is acceptable. You argue that scalar type
>>> declarations are relatively new, but in fact they're already years old now.
>>> They're used in most PHP 7+ packages. Even if changing types might be
>>> discouraged, it still happens a lot.
>>>
>>
>> Hmm.  Well, that aspect of this can be dropped. What about the rest of it?