[PHP-DEV] Union Type (singular) straw man proposal

[Mike Schinkel]

Hello all,

I'll start by saying I've been lurking for about six weeks and reading 
everything on the list since then although I was on the list for a short period 
many years ago.  

I recently took on a role as "WordPress Engineering Team Lead" and as such have 
gotten much more interested in revisiting PHP's feature set hence why I 
rejoined the list.  I've been working with PHP for 12 years, programming 
professionally for 32 years and GoLang the last 1+ years. So while I specialize 
in WordPress and PHP/MySQL, my experience has been in other frameworks and 
languages for most of my professional programming career.

I have been planning to write up an RFC regarding union types, but had not 
found the time. Seeing that Nikita has started a new RFC for Union Types v2 — 
how do you all keep up with that guy?!? — I realized that I better get these 
ideas at somewhat documented and presented or the train will have fully left 
the station.

What I am proposing can be layered on top of Nikita's proposal, and was 
influenced by what I have learned using Go. It is not a Go feature, but 
inspired by the Go interface{} type (which is a very different concept compared 
to interfaces in PHP, btw.)

It is a straw man proposal which means it is not a fully-fleshed out RFC, but 
if I waited until I had the time to write an RFC then PHP 8 might already be 
out:

Without further ado:

https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117 



Since I'm effectively new to the list this time please go easy on me? :-)

Thanks in advance for all your consideration.

-Mike Schinkel

Re: [PHP-DEV] MODERATE spam

[Sascha Schumann]

Looking good (test 3).

Please alert syst...@php.net if you have issues sending emails to 
*@lists.php.net.

Sascha

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

Re: [PHP-DEV] MODERATE spam

[Sascha Schumann]

And this would be test message 2. Sorry about this.

Sascha

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

Re: [PHP-DEV] MODERATE spam

[Sascha Schumann]

We have enabled the normal php.net spam protections for lists.php.net - this is 
test message 1.

Sascha

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

Re: [PHP-DEV] MODERATE spam

[Sascha Schumann]

When sending an email to php-announce@ ..

ezmlm-store:_info:_qp_26188/ezmlm-clean:_info:_qp_26206/Old_format_or_corrupted_index._Run_ezmlm-idx!_(#5.3.0)/ezmlm-warn:_info:_qp_26212/ezmlm-warn:_info:_qp_26219/ezmlm-warn:_info:_qp_26220/did_0+0+10/

I ran ezmlm-idx, looks better now.

Regarding delivery attempts to:

cmbecke...@gmx.de -> 

failure: 
212.227.17.5_failed_after_I_sent_the_message./Remote_host_said:_554-Transaction_failed/554-Reject_due_to_policy_restrictions./554_For_explanation_visit_http://postmaster.gmx.com/en/error-messages?ip=76.75.200.58=hd/

GMX rejects the messages from lists.php.net, possibly due to excessive spam 
from that IP address.

Cheers
Sascha

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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Andreas Hennings]

I would like to make a wild proposal.

## Proposal

Similar to spl_autoload_register(), we would provide a function that
allows to register a callback to provide the declares / edition /
compatibility information for a given file, before this file is
loaded.

To address performance concerns:
- The result of the callback is cached per file, and per "application
cache key". (*)
- The callback has the option to additionally provide compatibility
information for an entire directory, or a path pattern.

Callback signature:
- The primary parameter is the absolute path of the file, after
symlinks are resolved.
- Additional parameters could provide the version of the path that was
passed to include / require.
- An additional parameter could provide the class name, if we are
currently doing autoload lookup (ouch, this could be complicated).
- An additional parameter could contain the namespace. This would
require that the parsing already begins, before the compatibility
information is available.
- An additional parameter could contain class names and function names
declared in the file. This would imply that the file is already parsed
before the compatibility information is available.

(*) Caching mechanism:
- Different PHP "applications" can have different cache keys, so that
they do not poison each other. This could be provided in the initial
function call along with the callback.
- If no cache key is provided, the starting script path is used (e.g.
/path/to/index.php)
- There needs to be a function to clear this cache for the current application.
- The opcache could contain different versions of a file for different
compatibility levels.

Combination with other proposals:
There could still be functions to set compatibility information for an
entire directory or namespace preemptively.
There could also be ways to disable this special file-by-file callback
for specific directories or namespaces.


## Motivation

We saw proposals where the "edition" or "declares" would be on file
level, on namespace level, on directory level, or on package level.
The basic idea (mostly) was that the author provides compatibility
information which is then picked up by PHP.
The author of a package should be responsible for this, and it should
be protected from side effects from other packages.
Any file or package should have one definitive compatibility info,
which should not be changed from outside.

The proposal turns this on its head.
It is now the responsibility of the package manager (e.g. Composer) or
the framework to organize different compatibility levels in the
application.

Once some conventions have been established by the community (e.g.
Composer), the IDE can extract information from e.g. composer.json to
apply the appropriate checks on each file.

Benefits:
- Fine-grained control where needed, e.g. override the directory-level
or namespace-level compatibility information for specific files.
- Keep boilerplate out of the file header. No need to update all files
when a new compatibility type / edition is released.
- No verbose and noisy git commits in the package history.
- Option for shared compatibility information across "packages", e.g.
for the entire application.
- No need for an artificial "package" concept on language level. Let
community tools (e.g. Composer) define what a package is.
- Possibility to test-run an application or specific files with
different compatibility level.
- Possibility to control compatibility level based on dynamic file
lists, which can be updated based on error statistics, or which can be
updated file by file to slowly make an existing codebase compliant
with a new version.
- The average developer only needs to learn the API of the framework
or package manager, and does not need to deal with this on language
level.

Flaws:
- No explicit compatibility information when looking at a specific file.


## Assumptions

It is a assumed that "compatibility level" does NOT change the meaning of code.
When running a file with a different compatibility level than it was
designed for, we may get errors and warnings, but we do not want to
get silent changes in behavior.


Now I want to see this idea being barbecued..

On Wed, 14 Aug 2019 at 12:27, Michał Brzuchalski  wrote:
>
> śr., 14 sie 2019 o 12:17 Michał Brzuchalski 
> napisał(a):
>
> >
> >
> > śr., 14 sie 2019 o 12:11 Rowan Collins 
> > napisał(a):
> >
> >> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> >> > Exactly so how would it know from string name either it should load
> >> class
> >> > from src/Foo.php or src/__nsmeta.php if there is no information?
> >>
> >>
> >> It wouldn't. It would include src/Foo.php, and that would have the
> >> definition of something with the name "Foo" - either a class, an
> >> interface, a trait, or a package. If it wasn't what the engine was
> >> expecting, it would be an error, just as it is right now if you write
> >> "implements ClassName", or "new TraitName();"
> >>
> >
> > Following that would introduce 

Re: [PHP-DEV] Silent Types

[M. W. Moe]

Hello,

this would be very possible constant with the actual without breaking BC

allow declare var = value : type; -> throws if assignment + type  fails
the grammar context is exactly the same than a function return.

Best.


On Wed, Sep 4, 2019 at 10:18 AM Andreas Hennings 
wrote:

> On Wed, 4 Sep 2019 at 09:22, Lynn  wrote:
> >
> > Note that this behavior would require making some decisions whether or
> not
> > in the future this opt-in behavior should change when a default value is
> > given, such as with C# and type inference when declaring a variable,
> based
> > on its assigned value.
>
> I think this would too easily lead to mistakes.
> E.g. if in a git commit, "$x = 5.6;" is replaced with "$x = 5;" or "$x
> = '5.6';", then would a reviewer notice that this implicitly changes
> the type?
> Also, what if the initialization is inside an if branch? Later the
> if/else gets reordered, or one of the conditional branches gets
> removed, and the variable changes its type?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Silent Types

[Andreas Hennings]

On Wed, 4 Sep 2019 at 09:22, Lynn  wrote:
>
> Note that this behavior would require making some decisions whether or not
> in the future this opt-in behavior should change when a default value is
> given, such as with C# and type inference when declaring a variable, based
> on its assigned value.

I think this would too easily lead to mistakes.
E.g. if in a git commit, "$x = 5.6;" is replaced with "$x = 5;" or "$x
= '5.6';", then would a reviewer notice that this implicitly changes
the type?
Also, what if the initialization is inside an if branch? Later the
if/else gets reordered, or one of the conditional branches gets
removed, and the variable changes its type?

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

Re: [PHP-DEV] Silent Types

[Andreas Hennings]

On Wed, 4 Sep 2019 at 18:09, Ben Ramsey  wrote:
>
> > Andreas Hennings wrote:
> >
> > In some other languages the mixed type is called "variant".
> > https://en.m.wikipedia.org/wiki/Variant_type
> > I mostly remember it from VisualBasic.
>
> Union types are probably better than specifying a variant or mixed type. At 
> present, parameters and properties with no type specified are mixed by 
> default. Nikita has just opened discussion on a new union types proposal in 
> another thread.

Nothing wrong about union types, but this is a different topic.

A "mixed" or "variant" type is simply giving a name to what we already
have. Like the invention of the number zero.

Currently afaik a variable with a type specifier is simply a
variant/mixed variable with type checking added on. Which means every
variable has to store the current value type.
In other languages, typed variables are implemented without the
dynamic type information, and only the variant/mixed/union types need
this additional overhead.
If we introduce this to PHP in the future at some point, this would
allow for some nice optimization.

>
>
> > Fwentish Aelondes wrote:
> >
> > Hello internals,
> >
> > Zeev's idea to bring peace to the galaxy seems like a good idea, but
> > impossible to implement in practice.
> >
> > But it got me thinking about how one might introduce static typing
> > into a dynamically typed language w/out breaking BC.
> >
> > And then I had this crazy idea:
> >
> > //int
> > $i = 0;
> >
> > //string
> > $c = 'c';
> >
> > //float
> > $pi = 3.14;
> >
> > If static typing in php was *only* an opt-in kind-of-thing, would this
> > work? Could the parser be built to identify 3 or 4 different keywords
> > in comments and give warnings or fatal errors for type conversions of
> > variables that have the type specified in the immediately preceding
> > comment?
>
> Static analyzers (like PHPStan) already honor types specified in comments 
> above variables.
>
> /* @param int */
> $i = 0;
>
>
> > Michał Brzuchalski wrote:
> >
> > IMO it's crazy idea and we should not change the way comments work
> > especially inline comments which even aren't kept in opcache.
> >
> > I think better approach would be to put type in front of first variable
> > declaration like:
> >
> > [type] $variable = $value;
>
> I think specifying the type in front of the variable is the best option, and 
> we have precedence for this with typed properties in PHP 7.4.
>
>
> Cheers,
> Ben

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

Re: [PHP-DEV] Silent Types

[Ben Ramsey]

> Andreas Hennings wrote:
> 
> In some other languages the mixed type is called "variant".
> https://en.m.wikipedia.org/wiki/Variant_type
> I mostly remember it from VisualBasic.

Union types are probably better than specifying a variant or mixed type. At 
present, parameters and properties with no type specified are mixed by default. 
Nikita has just opened discussion on a new union types proposal in another 
thread.


> Fwentish Aelondes wrote:
> 
> Hello internals,
> 
> Zeev's idea to bring peace to the galaxy seems like a good idea, but
> impossible to implement in practice.
> 
> But it got me thinking about how one might introduce static typing
> into a dynamically typed language w/out breaking BC.
> 
> And then I had this crazy idea:
> 
> //int
> $i = 0;
> 
> //string
> $c = 'c';
> 
> //float
> $pi = 3.14;
> 
> If static typing in php was *only* an opt-in kind-of-thing, would this
> work? Could the parser be built to identify 3 or 4 different keywords
> in comments and give warnings or fatal errors for type conversions of
> variables that have the type specified in the immediately preceding
> comment?

Static analyzers (like PHPStan) already honor types specified in comments above 
variables.

/* @param int */
$i = 0;


> Michał Brzuchalski wrote:
> 
> IMO it's crazy idea and we should not change the way comments work
> especially inline comments which even aren't kept in opcache.
> 
> I think better approach would be to put type in front of first variable
> declaration like:
> 
> [type] $variable = $value;

I think specifying the type in front of the variable is the best option, and we 
have precedence for this with typed properties in PHP 7.4.


Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Silent Types

[Larry Garfield]

On Wed, Sep 4, 2019, at 2:21 AM, Lynn wrote:
> Hi,
> 
> Would this warrant a having mixed types? By making every variable of type
> "mixed" when no type is defined, regardless of what value it receives or is
> initialized with, this would make an opt-in system. This behavior would
> cater developers who prefer only strict types, only dynamic types, and
> those that want to type their code bit by bit without putting declares that
> affect whole files.
> 
> ```
> $foo = 'foo';
> // same as
> mixed $oneHundred = 100;
> // difference being:
> // $foo is accepted when 'string' is typed in the signature
> // $oneHundred is accepted when 'int' is typed in the signature
> 
> // no longer mixed, only accepts their defined type as value
> // and is accepted only as their defined type in signatures
> string $foo = 'foo';
> int $oneHundred = 100;

Yes, an implicit "mixed" type would be the only way it could be done, just like 
object properties that are not explicitly typed are implicitly "mixed".  
Whether there is a "mixed" type for explicit declaration is an open question; 
if it were added, it would IMO make sense to add for properties and 
parameters/returns, as well, for consistency.  Whether or not that's wise in 
general I don't know.

> // does imply we might need custom type definitions in the future to not
> have to work with mixed
> typedef Stringable = string | MyToStringInterface;
> Stringable $foo = (bool) rand(0, 1) ? 'foo' : new MyStringableObject('foo');
> ```

There's a long list of reasons we want that functionality even before we get to 
variable types. :-)  IIRC, it falls into the popular category of "this would be 
really useful but is harder than it sounds for complex implementation reasons, 
and a few people feel it's too much ceremony for a loose language."  There's a 
number of features stuck in that bucket.

> Note that this behavior would require making some decisions whether or not
> in the future this opt-in behavior should change when a default value is
> given, such as with C# and type inference when declaring a variable, based
> on its assigned value.

I could see arguments either way, but BC would probably dictate that types are 
not set implicitly.  Otherwise, this currently valid code would break:

$things = 'foo';
...
$things = ['foo', 'bar'];

if (is_array($things)) { ... }
else { ... }

(Whether or not that's good practice is beside the point; there's ample code 
like that out there and breaking it when we don't have to is a no-no.)

--Larry Garfield

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

Re: [PHP-DEV] Windows builds of PHP 7.4+ use Visual Studio 2019

[Christoph M. Becker]

On 04.09.2019 at 15:23, Björn Larsson wrote:

> Den 2019-06-06 kl. 14:11, skrev Christoph M. Becker:
>
>> I like to inform you, that the official Windows builds of PHP 7.4 and
>> master (available from windows.php.net; currently only snapshot builds,
>> of course) are done with Visual Studio 2019.  While it is still possible
>> to build these PHP versions with Visual Studio 2017, this is no longer
>> tested.
>>
>> This also means a small but important change, namely that we are no
>> longer using the "vc" prefix (e.g. "vc14", "vc15") to refer to *new*
>> Visual Studio versions, but rather "vs" (i.e. "vs16").  The detailed
>> reasoning is explained in the post titled "Visual Studio 2019
>> Builds"[1].  Recent beta versions of the PHP SDK are supposed to fully
>> support this naming change already (and particularly the renaming of the
>> PHP_SDK_VC environment variable to PHP_SDK_VS).  You may have to adapt
>> custom tooling accordingly, though.
>>
>> Thanks,
>> Christoph
>>
>> [1] 
>
> This is a welcome change. For beta 3 and earlier I got the error message:
> $ php -v
> PHP Warning:  'vcruntime140.dll' 14.11 is not compatible with this PHP
> build linked with 14.21 in Unknown on line 0
>
> Now it works out of the box on my win 8.1 machien!
> $ php -v
> PHP 7.4.0-dev (cli) (built: Sep  4 2019 09:49:12) ( NTS Visual C++ 2017
> x64 )
> Copyright (c) The PHP Group
> Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

You could (and still can) install the Visual C++ Redistributable for
Visual Studio 2015-2019, though:




--
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Union Types v2

[Claude Pache]

> Le 4 sept. 2019 à 13:54, Dan Ackroyd  a écrit :
> 
>> 
>> if we were to use "?int" instead, the engine would force the
>> community to add "return null;"
> 
> That sounds like a bug to me. The fact that null is returned by any
> function that lacks an explicit return value, is well-defined, and one
> of the most underrated aspects of PHP imo.
> 

This is an aspect of the eternal debate between explicit vs. implicit. In 
another recent thread, another aspect, namely variable initialisation, was 
debated. There is no “correct” solution, as it pertains much to coding style.

—Claude

Re: [PHP-DEV] Windows builds of PHP 7.4+ use Visual Studio 2019

[Björn Larsson]

Den 2019-06-06 kl. 14:11, skrev Christoph M. Becker:

Hi,

I like to inform you, that the official Windows builds of PHP 7.4 and
master (available from windows.php.net; currently only snapshot builds,
of course) are done with Visual Studio 2019.  While it is still possible
to build these PHP versions with Visual Studio 2017, this is no longer
tested.

This also means a small but important change, namely that we are no
longer using the "vc" prefix (e.g. "vc14", "vc15") to refer to *new*
Visual Studio versions, but rather "vs" (i.e. "vs16").  The detailed
reasoning is explained in the post titled "Visual Studio 2019
Builds"[1].  Recent beta versions of the PHP SDK are supposed to fully
support this naming change already (and particularly the renaming of the
PHP_SDK_VC environment variable to PHP_SDK_VS).  You may have to adapt
custom tooling accordingly, though.

Thanks,
Christoph

[1] 


Hi,

This is a welcome change. For beta 3 and earlier I got the error message:
$ php -v
PHP Warning:  'vcruntime140.dll' 14.11 is not compatible with this PHP 
build linked with 14.21 in Unknown on line 0


Now it works out of the box on my win 8.1 machien!
$ php -v
PHP 7.4.0-dev (cli) (built: Sep  4 2019 09:49:12) ( NTS Visual C++ 2017 
x64 )

Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

r//Björn L

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

[PHP-DEV] PHP 7 + bcgen extension + PHAR extension

[Henrik Skov]

Hi !

I hope this is the right mailing list to post my request to.

I found a port of bcompiler here:

https://github.com/vjardin/bcgen/

which is PHP7 compatible.

By mailing here, I am trying to reach out to the authors of the PHAR 
extension since the author(s) of bcgen have said that they don't know 
enough about the PHAR extension.


I am trying to get bcgen to work with PHAR files. I have added the 
compiled PHP files to the PHAR file (using their PHP extension within 
the PHAR file)


The stub of the PHP archive is:

|#!/usr/bin/env php|
|

The file app.php is in the root of the PHAR archive and is compiled by 
bcgen.


When I run the phar (on the commandline), all I get is some gibberish 
output (to STDOUT) and the process exits with exitcode 130 ?


My understanding is that bcgen extension will inspect the file which is 
included/required (ie. app.php) and then - if it is bytecode - then 
simply execute the bytecode - If it is not, then it will parse the 
included file normally ? (from the description found in the README of 
bcgen in github)


However it seems that what actually happens, is that the header of the 
PHAR file itself is checked and since that is obviously not a BCGEN 
header or a normal PHP file, processing is aborted.


If we could skip this check when running from a PHAR archive (from the 
commandline or when the PHAR is included within some other PHP file) and 
in this scenario only "react" to include/require/autoloading statements 
(ie. check if a file that is about to be included is bytecode or not - 
if it is, then run it - If it is not then compile it first and then run 
the resulting bytecode), then - in my humble opinion - we would have a 
way of adding minimal protection to PHAR files - useful when 
redistributing PHARs (since such a PHAR archive would then simply 
contain a number of files that are bytecode - except for the stub of 
course...) and that would - I think - make PHAR files even cooler and 
provide a most sought-after feature.


Could anyone help getting "PHAR support" to work with the bcgen 
extension ? I would be willing to help but my C skills are not that 
great and I know little about the ZendEngine.


Thanks in advance !

Best regards,

Henrik Skov
Secuno A/S
www.secuno.dk

Re: [PHP-DEV] [RFC] Union Types v2

[Dan Ackroyd]

On Wed, 4 Sep 2019 at 10:59, Nicolas Grekas
 wrote:

> we use "@return $this" quite often. On the implementation side, I'd
> suggest enforcing this at compile time only (enforce all return points are
> explicit, and written as "return $this"

That's doing a deeper level of thing than a type system normal does.

It's enforcing the internal behaviour of a function, rather than just
defining the type of the parameter that is returned.


> if we were to use "?int" instead, the engine would force the
> community to add "return null;"

That sounds like a bug to me. The fact that null is returned by any
function that lacks an explicit return value, is well-defined, and one
of the most underrated aspects of PHP imo.


Arnold Daniels wrote:
> Instead of using `__toString` as type maybe it's better to introduce
> a `Stringable` interface,

Although casting things to string is probably the most common use
case, if you're going to think about an RFC along those lines,
covering all of the scalars would probably be a good idea, as that
would allow people to use specific types for values, that can then be
passed easily to functions that expect a scalar.

function setRetryLimit(int $maxRetries) {...}

class ImageUploadRetryLimit extends int {...}

function processImage(ImageUploadRetryLimit $iurl, ) {
...
setRetryLimit($iurl);
...
}

That type* of stuff is completely possible currently in PHP, it's just
that it's a bit painful to both write and read.

cheers
Dan
Ack


*intended

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

Re: [PHP-DEV] [RFC] Union Types v2

[Peter Bowyer]

On Wed, 4 Sep 2019 at 12:30, Arnold Daniels 
wrote:

> Instead of using `__toString` as type maybe it's better to introduce a
> `Stringable` interface, similar to how `__wakeup` and `__sleep` are already
> superseded by `Serializable`.


I support that.  I don't like the naming in `string|__toString`.
`string|Stringable` is more readable IMO.

Peter

Re: [PHP-DEV] [RFC] Union Types v2

[Arnold Daniels]

Instead of using `__toString` as type maybe it's better to introduce a 
`Stringable` interface, similar to how `__wakeup` and `__sleep` are already 
superseded by `Serializable`. Of course `__toString` would still continue to 
work (for bc), but isn't usable for type hinting.

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5acb3)
[5acb3]

On September 4, 2019 at 9:59 GMT, Nicolas Grekas  
wrote:

Re: [PHP-DEV] [RFC] Union Types v2

[Matthew Brown]

- Agree on the usefulness of a stringable meta-type.

- Hack supports an explicit “: this” return type (without dollar) when 
returning “new static(...)”. I think I might prefer that to “: static”.

- From a type perspective, I don’t understand the “int|void” idea - it might 
make your users’ life easier, but doesn’t accord with how PHP works (which 
treats void as null to consumers).

- if we’re adding to some future wish list, would love to have support for “: 
noreturn” when a function always throws or exits

On Sep 4, 2019, at 5:58 AM, Nicolas Grekas  wrote:

>> 
>> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
> 
> 
> Thank you Nikita, this would be a hugely welcomed step forward! Can't wait
> to get rid of all those docblock annotations!
> 
> I've some additional suggestions that would greatly help remove more
> docblocks and provide engine-enforced type-safety, maybe for the "future
> scope" section. We use the all in Symfony:
> 
>   - we miss a stringable union type, for `string|__toString`. This is
>   required when an API need lazyness regarding the generation of some
>   strings. Right now, we have no other option but using string|object.
>   - we use "@return $this" quite often. On the implementation side, I'd
>   suggest enforcing this at compile time only (enforce all return points are
>   explicit, and written as "return $this", similarly to what is done for
>   nullable/void return types.) This makes sense only for return types.
>   - we use "@return static" quite often too, typically when a method
>   returns a clone of the current instance. If anyone wonders, this is not the
>   same as "@return self" of methods overridden in child classes. This makes
>   sense only for return types.
> 
> About union types with void in them, we do use one in Symfony:
> Command::execute() has "@return int|void". The reason is that if we were to
> use "?int" instead, the engine would force the community to add "return
> null;" where no return statement is needed at all most of the time. Right
> now, we consider that the transition cost for the community is not worth
> the extra boilerplate this requires. Note that there would be only one
> friendly path forward: trigger a deprecation when null is returned, asking
> ppl to add  "return 0;". Not sure how this should impact the proposal, but
> I thought it could be worth sharing.
> 
> Thanks again,
> Nicolas

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

Re: [PHP-DEV] [RFC] Union Types v2

[Nicolas Grekas]

>
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md


Thank you Nikita, this would be a hugely welcomed step forward! Can't wait
to get rid of all those docblock annotations!

I've some additional suggestions that would greatly help remove more
docblocks and provide engine-enforced type-safety, maybe for the "future
scope" section. We use the all in Symfony:

   - we miss a stringable union type, for `string|__toString`. This is
   required when an API need lazyness regarding the generation of some
   strings. Right now, we have no other option but using string|object.
   - we use "@return $this" quite often. On the implementation side, I'd
   suggest enforcing this at compile time only (enforce all return points are
   explicit, and written as "return $this", similarly to what is done for
   nullable/void return types.) This makes sense only for return types.
   - we use "@return static" quite often too, typically when a method
   returns a clone of the current instance. If anyone wonders, this is not the
   same as "@return self" of methods overridden in child classes. This makes
   sense only for return types.

About union types with void in them, we do use one in Symfony:
Command::execute() has "@return int|void". The reason is that if we were to
use "?int" instead, the engine would force the community to add "return
null;" where no return statement is needed at all most of the time. Right
now, we consider that the transition cost for the community is not worth
the extra boilerplate this requires. Note that there would be only one
friendly path forward: trigger a deprecation when null is returned, asking
ppl to add  "return 0;". Not sure how this should impact the proposal, but
I thought it could be worth sharing.

Thanks again,
Nicolas

Re: [PHP-DEV] [RFC] Union Types v2

[Aegir Leet]

On the subject of using GitHub for this RFC:

Personally, I think GitHub is a much better platform than the mailing 
list for this kind of discussion. Mailing list threads are just not very 
accessible to the average PHP user. Reading them through externals.io is 
an OK experience, but actually contributing is unnecessarily complicated.

I'd imagine most people aren't really interested in something like the 
recent "Annotating internal function argument and return types​" thread, 
but would very much like to participate in a discussion (even if it's 
just leaving a "+1") about something that affects their day-to-day work, 
like union types.

Generally, I'd split things up like this:
Truly internal work on PHP itself, things only people working *on* PHP 
(as opposed to *with* PHP) really care about -> internals.
Changes affecting regular PHP users, RFCs for adding or removing 
features and things like that -> GitHub or some other platform where 
everyone can easily contribute.


On 04.09.19 10:26, Nikita Popov wrote:
> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>
> Relatively to the previous proposal by Bob (
> https://wiki.php.net/rfc/union_types), I think the main differences in this
> proposal are:
>   * Updated to specify interaction with new language features, like full
> variance and property types.
>   * Updated for the use of the ?Type syntax rather than the Type|null syntax.
>   * Only supports "false" as a pseudo-type, not "true".
>   * Slightly simplified semantics for the coercive typing mode.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Union Types v2

[Marco Pivetta]

Hey Nikita,

On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
>
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>

Huge huge huge +1! Reviewing line-by-line allowed me to go much more in
detail with the feedback :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] [RFC] Union Types v2

[Nikita Popov]

Hi internals,

I'd like to start the discussion on union types again, with a new proposal:

Pull Request: https://github.com/php/php-rfcs/pull/1
Rendered Proposal:
https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md

As an experiment, I'm submitting this RFC as a GitHub pull request, to
evaluate whether this might be a better medium for RFC proposals in the
future. It would be great if we could keep the discussion to the GitHub
pull request for the purpose of this experiment (keep in mind that you can
also create comments on specific lines in the proposal, not just the
overall discussion thread!) Of course, you can also reply to this mail
instead. The final vote will be held in the wiki as usual.

Relatively to the previous proposal by Bob (
https://wiki.php.net/rfc/union_types), I think the main differences in this
proposal are:
 * Updated to specify interaction with new language features, like full
variance and property types.
 * Updated for the use of the ?Type syntax rather than the Type|null syntax.
 * Only supports "false" as a pseudo-type, not "true".
 * Slightly simplified semantics for the coercive typing mode.

Regards,
Nikita

Re: [PHP-DEV] Silent Types

[Andreas Hennings]

In some other languages the mixed type is called "variant".
https://en.m.wikipedia.org/wiki/Variant_type
I mostly remember it from VisualBasic.

Lynn  schrieb am Mi., 4. Sep. 2019, 09:22:

> Hi,
>
> Would this warrant a having mixed types? By making every variable of type
> "mixed" when no type is defined, regardless of what value it receives or is
> initialized with, this would make an opt-in system. This behavior would
> cater developers who prefer only strict types, only dynamic types, and
> those that want to type their code bit by bit without putting declares that
> affect whole files.
>
> ```
> $foo = 'foo';
> // same as
> mixed $oneHundred = 100;
> // difference being:
> // $foo is accepted when 'string' is typed in the signature
> // $oneHundred is accepted when 'int' is typed in the signature
>
> // no longer mixed, only accepts their defined type as value
> // and is accepted only as their defined type in signatures
> string $foo = 'foo';
> int $oneHundred = 100;
>
> // does imply we might need custom type definitions in the future to not
> have to work with mixed
> typedef Stringable = string | MyToStringInterface;
> Stringable $foo = (bool) rand(0, 1) ? 'foo' : new
> MyStringableObject('foo');
> ```
>
> Note that this behavior would require making some decisions whether or not
> in the future this opt-in behavior should change when a default value is
> given, such as with C# and type inference when declaring a variable, based
> on its assigned value.
>
> Regards,
> Lynn van der Berg
>
> On Wed, Sep 4, 2019 at 8:12 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > śr., 4 wrz 2019, 05:52 użytkownik Fwentish Aelondes 
> > napisał:
> >
> > > Hello internals,
> > >
> > > Zeev's idea to bring peace to the galaxy seems like a good idea, but
> > > impossible to implement in practice.
> > >
> > > But it got me thinking about how one might introduce static typing
> > > into a dynamically typed language w/out breaking BC.
> > >
> > > And then I had this crazy idea:
> > >
> > > //int
> > > $i = 0;
> > >
> > > //string
> > > $c = 'c';
> > >
> > > //float
> > > $pi = 3.14;
> > >
> > > If static typing in php was *only* an opt-in kind-of-thing, would this
> > > work? Could the parser be built to identify 3 or 4 different keywords
> > > in comments and give warnings or fatal errors for type conversions of
> > > variables that have the type specified in the immediately preceding
> > > comment?
> > >
> > > Just a (crazy) idea.
> > >
> > >  Fwentish
> >
> >
> > IMO it's crazy idea and we should not change the way comments work
> > especially inline comments which even aren't kept in opcache.
> >
> > I think better approach would be to put type in front of first variable
> > declaration like:
> >
> > [type] $variable = $value;
> >
> >
> > BR,
> > --
> > Michał Brzuchalski
> >
>

Re: [PHP-DEV] Silent Types

[Lynn]

Hi,

Would this warrant a having mixed types? By making every variable of type
"mixed" when no type is defined, regardless of what value it receives or is
initialized with, this would make an opt-in system. This behavior would
cater developers who prefer only strict types, only dynamic types, and
those that want to type their code bit by bit without putting declares that
affect whole files.

```
$foo = 'foo';
// same as
mixed $oneHundred = 100;
// difference being:
// $foo is accepted when 'string' is typed in the signature
// $oneHundred is accepted when 'int' is typed in the signature

// no longer mixed, only accepts their defined type as value
// and is accepted only as their defined type in signatures
string $foo = 'foo';
int $oneHundred = 100;

// does imply we might need custom type definitions in the future to not
have to work with mixed
typedef Stringable = string | MyToStringInterface;
Stringable $foo = (bool) rand(0, 1) ? 'foo' : new MyStringableObject('foo');
```

Note that this behavior would require making some decisions whether or not
in the future this opt-in behavior should change when a default value is
given, such as with C# and type inference when declaring a variable, based
on its assigned value.

Regards,
Lynn van der Berg

On Wed, Sep 4, 2019 at 8:12 AM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> śr., 4 wrz 2019, 05:52 użytkownik Fwentish Aelondes 
> napisał:
>
> > Hello internals,
> >
> > Zeev's idea to bring peace to the galaxy seems like a good idea, but
> > impossible to implement in practice.
> >
> > But it got me thinking about how one might introduce static typing
> > into a dynamically typed language w/out breaking BC.
> >
> > And then I had this crazy idea:
> >
> > //int
> > $i = 0;
> >
> > //string
> > $c = 'c';
> >
> > //float
> > $pi = 3.14;
> >
> > If static typing in php was *only* an opt-in kind-of-thing, would this
> > work? Could the parser be built to identify 3 or 4 different keywords
> > in comments and give warnings or fatal errors for type conversions of
> > variables that have the type specified in the immediately preceding
> > comment?
> >
> > Just a (crazy) idea.
> >
> >  Fwentish
>
>
> IMO it's crazy idea and we should not change the way comments work
> especially inline comments which even aren't kept in opcache.
>
> I think better approach would be to put type in front of first variable
> declaration like:
>
> [type] $variable = $value;
>
>
> BR,
> --
> Michał Brzuchalski
>

Re: [PHP-DEV] Silent Types

[Michał Brzuchalski]

śr., 4 wrz 2019, 05:52 użytkownik Fwentish Aelondes 
napisał:

> Hello internals,
>
> Zeev's idea to bring peace to the galaxy seems like a good idea, but
> impossible to implement in practice.
>
> But it got me thinking about how one might introduce static typing
> into a dynamically typed language w/out breaking BC.
>
> And then I had this crazy idea:
>
> //int
> $i = 0;
>
> //string
> $c = 'c';
>
> //float
> $pi = 3.14;
>
> If static typing in php was *only* an opt-in kind-of-thing, would this
> work? Could the parser be built to identify 3 or 4 different keywords
> in comments and give warnings or fatal errors for type conversions of
> variables that have the type specified in the immediately preceding
> comment?
>
> Just a (crazy) idea.
>
>  Fwentish


IMO it's crazy idea and we should not change the way comments work
especially inline comments which even aren't kept in opcache.

I think better approach would be to put type in front of first variable
declaration like:

[type] $variable = $value;


BR,
--
Michał Brzuchalski