[RFC] [DISCUSSION] Ensure correct magic methods' signatures when typed

  109542
April 5, 2020 14:01 carusogabriel34@gmail.com (Gabriel Caruso)
Hello, internals.

Hereby you can find the RFC Document that I want to discuss as suggested
via https://externals.io/message/109416 and
https://externals.io/message/107990:

https://wiki.php.net/rfc/magic-methods-signature

Best regards,

-- Gabriel Caruso
  109547
April 7, 2020 10:55 claude.pache@gmail.com (Claude Pache)
> Le 5 avr. 2020 à 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a écrit : > > Hello, internals. > > Hereby you can find the RFC Document that I want to discuss as suggested > via https://externals.io/message/109416 and > https://externals.io/message/107990: > > https://wiki.php.net/rfc/magic-methods-signature > > Best regards, > > -- Gabriel Caruso
Hi, Regarding __construct(), etc. Since those methods are not supposed to return anything, they ought to accept the `void` return pseudo-type in their signature, which means exactly that: “do not return anything”. I consider that the current behaviour (i.e., not accepting the `: void` signature) as a bug, and was very surprised when I stumbled on it. ------------ Also, I raise the following question: Should omitted types be added implicitly? I.e., if I write: `function __toString() { }` should the compiler interpret it as `function __toString(): string { }` ? (Currently, it is not the case.) Doing so would raise BC concerns for some, uh, creative uses of magic methods. On the other hand, that may help to add progressively type informations on magic methods, since there is no need to synchronise manually classes and subclasses (the compiler would do it automatically for you). Concrete example here: https://3v4l.org/hTMvA <https://3v4l.org/hTMvA> —Claude
  109588
April 11, 2020 20:40 carusogabriel34@gmail.com (Gabriel Caruso)
On Tue, 7 Apr 2020 at 12:55, Claude Pache pache@gmail.com> wrote:

> > Le 5 avr. 2020 à 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a > écrit : > > Hello, internals. > > Hereby you can find the RFC Document that I want to discuss as suggested > via https://externals.io/message/109416 and > https://externals.io/message/107990: > > https://wiki.php.net/rfc/magic-methods-signature > > Best regards, > > -- Gabriel Caruso > > > Hi, >
Hello Claude,
> > Regarding __construct(), etc. Since those methods are not supposed to > return anything, they ought to accept the `void` return pseudo-type in > their signature, which means exactly that: “do not return anything”. I > consider that the current behaviour (i.e., not accepting the `: void` > signature) as a bug, and was very surprised when I stumbled on it. > > I'll add to the RFC adding the possibility of typing the `__construct()` as
`: void` as one of the changes.
> ------------ > > Also, I raise the following question: > > Should omitted types be added implicitly? I.e., if I write: `function > __toString() { }` should the compiler interpret it as `function > __toString(): string { }` ? (Currently, it is not the case.) > > Doing so would raise BC concerns for some, uh, creative uses of magic > methods. On the other hand, that may help to add progressively type > informations on magic methods, since there is no need to synchronise > manually classes and subclasses (the compiler would do it automatically for > you). Concrete example here: https://3v4l.org/hTMvA > > This RFC does not cover analyzing the return of magic methods nor adding
simplicity types. I'll add a note about it in the RFC.
> —Claude >
Thanks!
  109589
April 11, 2020 21:29 carusogabriel34@gmail.com (Gabriel Caruso)
On Sat, 11 Apr 2020 at 22:40, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> On Tue, 7 Apr 2020 at 12:55, Claude Pache pache@gmail.com> wrote: > >> >> Le 5 avr. 2020 à 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a >> écrit : >> >> Hello, internals. >> >> Hereby you can find the RFC Document that I want to discuss as suggested >> via https://externals.io/message/109416 and >> https://externals.io/message/107990: >> >> https://wiki.php.net/rfc/magic-methods-signature >> >> Best regards, >> >> -- Gabriel Caruso >> >> >> Hi, >> > > Hello Claude, > > >> >> Regarding __construct(), etc. Since those methods are not supposed to >> return anything, they ought to accept the `void` return pseudo-type in >> their signature, which means exactly that: “do not return anything”. I >> consider that the current behaviour (i.e., not accepting the `: void` >> signature) as a bug, and was very surprised when I stumbled on it. >> >> > I'll add to the RFC adding the possibility of typing the `__construct()` > as `: void` as one of the changes. > > >> ------------ >> >> Also, I raise the following question: >> >> Should omitted types be added implicitly? I.e., if I write: `function >> __toString() { }` should the compiler interpret it as `function >> __toString(): string { }` ? (Currently, it is not the case.) >> >> Doing so would raise BC concerns for some, uh, creative uses of magic >> methods. On the other hand, that may help to add progressively type >> informations on magic methods, since there is no need to synchronise >> manually classes and subclasses (the compiler would do it automatically for >> you). Concrete example here: https://3v4l.org/hTMvA >> >> > This RFC does not cover analyzing the return of magic methods nor adding > simplicity types. I'll add a note about it in the RFC. > > >> —Claude >> > > Thanks! >
Btw, the problem that you reported about incompatible signatures will be fixed on PHP 8: https://3v4l.org/hTMvA/rfc#git-php-master. I've also added a test on the implementation ensuring the following: https://3v4l.org/5010J/rfc#git-php-master. Thanks! -- Gabriel Caruso
  109624
April 14, 2020 13:09 carusogabriel34@gmail.com (Gabriel Caruso)
On Sat, 11 Apr 2020 at 23:29, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> On Sat, 11 Apr 2020 at 22:40, Gabriel Caruso <carusogabriel34@gmail.com> > wrote: > >> On Tue, 7 Apr 2020 at 12:55, Claude Pache pache@gmail.com> wrote: >> >>> >>> Le 5 avr. 2020 à 16:01, Gabriel Caruso <carusogabriel34@gmail.com> a >>> écrit : >>> >>> Hello, internals. >>> >>> Hereby you can find the RFC Document that I want to discuss as suggested >>> via https://externals.io/message/109416 and >>> https://externals.io/message/107990: >>> >>> https://wiki.php.net/rfc/magic-methods-signature >>> >>> Best regards, >>> >>> -- Gabriel Caruso >>> >>> >>> Hi, >>> >> >> Hello Claude, >> >> >>> >>> Regarding __construct(), etc. Since those methods are not supposed to >>> return anything, they ought to accept the `void` return pseudo-type in >>> their signature, which means exactly that: “do not return anything”. I >>> consider that the current behaviour (i.e., not accepting the `: void` >>> signature) as a bug, and was very surprised when I stumbled on it. >>> >>> >> I'll add to the RFC adding the possibility of typing the `__construct()` >> as `: void` as one of the changes. >> >> >>> ------------ >>> >>> Also, I raise the following question: >>> >>> Should omitted types be added implicitly? I.e., if I write: `function >>> __toString() { }` should the compiler interpret it as `function >>> __toString(): string { }` ? (Currently, it is not the case.) >>> >>> Doing so would raise BC concerns for some, uh, creative uses of magic >>> methods. On the other hand, that may help to add progressively type >>> informations on magic methods, since there is no need to synchronise >>> manually classes and subclasses (the compiler would do it automatically for >>> you). Concrete example here: https://3v4l.org/hTMvA >>> >>> >> This RFC does not cover analyzing the return of magic methods nor adding >> simplicity types. I'll add a note about it in the RFC. >> >> >>> —Claude >>> >> >> Thanks! >> > > Btw, the problem that you reported about incompatible signatures will be > fixed on PHP 8: https://3v4l.org/hTMvA/rfc#git-php-master. > > I've also added a test on the implementation ensuring the following: > https://3v4l.org/5010J/rfc#git-php-master. > > Thanks! > > -- Gabriel Caruso >
RFC and implementation have been updated. I'll open it for voting this Friday (17-04-2020) if there's anything else to discuss. Best regards,
  109625
April 14, 2020 13:24 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Hello Gabriel,

>>> https://wiki.php.net/rfc/magic-methods-signature > > RFC and implementation have been updated. >
There are a few things I don't understand from the RFC, let me list from the examples.
> This RFC proposes to introduce the following signatures checks when magic methods are typed:
My general question is: what does this mean exactly?
> /** @return mixed */ > Foo::__call(string $name, array $arguments);
> /** @return mixed */ > Foo::__callStatic(string $name, array $arguments);
> /** @return mixed */ > Foo::__get(string $name);
Does this mean we won't be allowed to declare __call($name, $arguments);? This looks against LSP to me.
> Foo::__clone(): void;
> /** @param mixed $args */ > Foo::__construct($args): void;
> Foo::__destruct(): void;
Is void going to be mandatory now? This should be specified in the RFC I think. If it's about to allow void where it wasn't allowed, I'm personally not convinced it's a good idea to open one more code-style war on this topic. When there is only one way to declare something, there is no need to come to any agreement about the code style. That's a win.
> Foo::__isset(string $name): bool; > Foo::__unset(string $name): void;
Same comment about LSP, but also about the type: isn't it allowed to have integers as keys? How does this play with strict_type and array access?
> /** @param mixed $value */ > Foo::__set(string $name, $value): void;
Is the return now going to be mandatory? And the BIG question: is all this worth the BC break? Thanks, Nicolas
  109626
April 14, 2020 13:46 carusogabriel34@gmail.com (Gabriel Caruso)
On Tue, 14 Apr 2020 at 15:24, Nicolas Grekas grekas+php@gmail.com>
wrote:

> Hello Gabriel, > > >>> https://wiki.php.net/rfc/magic-methods-signature >> >> RFC and implementation have been updated. >> > > There are a few things I don't understand from the RFC, let me list from > the examples. > > > This RFC proposes to introduce the following signatures checks when > magic methods are typed: > > My general question is: what does this mean exactly? > > > > /** @return mixed */ > > Foo::__call(string $name, array $arguments); > > > /** @return mixed */ > > Foo::__callStatic(string $name, array $arguments); > > > /** @return mixed */ > > Foo::__get(string $name); > > > Does this mean we won't be allowed to declare __call($name, $arguments);? > > This looks against LSP to me. > > > > Foo::__clone(): void; > > > /** @param mixed $args */ > > Foo::__construct($args): void; > > > Foo::__destruct(): void; > > Is void going to be mandatory now? This should be specified in the RFC I > think. > > If it's about to allow void where it wasn't allowed, I'm personally not > convinced it's a good idea to open one more code-style war on this topic. > When there is only one way to declare something, there is no need to come > to any agreement about the code style. That's a win. >
Hello Nicolas No, *nothing* is gonna be mandatory. As per the RFC:
> This RFC proposes to introduce the following signatures checks when magic methods are typed:
These checks are only gonna be performed when you type your signatures and *only when you type*. So, your example: `__call($name, $arguments)` will work just fine, same as if you don't type `__clone` with `: void`. Is there a better way to phrase that in the RFC?
> > > Foo::__isset(string $name): bool; > > Foo::__unset(string $name): void; > > Same comment about LSP, but also about the type: isn't it allowed to have > integers as keys? How does this play with strict_type and array access? > Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But, if
you call as a method, yes: https://3v4l.org/0VmYQ. So this should be documented in the RFC as a BC Break.
> > > /** @param mixed $value */ > > Foo::__set(string $name, $value): void; > > > Is the return now going to be mandatory? >
No, as explained above.
> And the BIG question: is all this worth the BC break? >
My main motivation is to make sure that developers are using the magic methods with the correct type, nothing else. If everyone then agrees that not having these checks is better for the language, no problem on closing this RFC :) Let me know your thoughts. Thanks,
> Thanks, > > Nicolas >
  109632
April 14, 2020 14:37 guilliam.xavier@gmail.com (Guilliam Xavier)
Hi, just chiming in on a specific question/answer:

On Tue, Apr 14, 2020 at 3:46 PM Gabriel Caruso
<carusogabriel34@gmail.com> wrote:
> > On Tue, 14 Apr 2020 at 15:24, Nicolas Grekas grekas+php@gmail.com> > wrote: > > > > > > Foo::__isset(string $name): bool; > > > Foo::__unset(string $name): void; > > > > Same comment about LSP, but also about the type: isn't it allowed to have > > integers as keys? How does this play with strict_type and array access? > > > Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But, if > you call as a method, yes: https://3v4l.org/0VmYQ.
Actually there are ways to use integers as property names, but they are converted to strings on creation: https://3v4l.org/0k4LS and https://3v4l.org/HhPZP (also https://3v4l.org/Ts42B). ArrayAccess doesn't use magic __isset(string $name) but interface offsetExists(mixed $offset). Regards, -- Guilliam Xavier
  109633
April 14, 2020 14:54 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> No, *nothing* is gonna be mandatory. > > As per the RFC: > > > This RFC proposes to introduce the following signatures checks when > magic methods are typed: > > These checks are only gonna be performed when you type your signatures and > *only when you type*. So, your example: `__call($name, $arguments)` will > work just fine, same as if you don't type `__clone` with `: void`. > > Is there a better way to phrase that in the RFC? >
OH, good news then. This should be formulated with more sentences I think, e.g:
> When any of the listed magic method use type hints, this RFC will enforce that only the supported types are used.
> When they don't declare a type, nothing specific will happen.
Also, add this somewhere maybe:
> This limits the BC break to methods that declare a wrong type.
Because this is what this is about, right?
> Thanks for raise this. Nowadays, you can't: https://3v4l.org/pPJDt. But, > if you call as a method, yes: https://3v4l.org/0VmYQ. > > So this should be documented in the RFC as a BC Break. >
Yes, the BC break is bigger when the magic methods are used directly, that's true and should be mentioned to.
> And the BIG question: is all this worth the BC break? >> > > My main motivation is to make sure that developers are using the magic > methods with the correct type, nothing else. If everyone then agrees that > not having these checks is better for the language, no problem on closing > this RFC :) >
Now that I understand that the scope of the BC break is quite narrow, I think you answered the question on my side. I'm just not sold on allowing "void" on __construct, because the very concept of a return type on a constructor is ... void, and also because of the code style choices this will open (and the CS "wars" I mentioned). Thanks, Nicolas
  109636
April 14, 2020 16:06 claude.pache@gmail.com (Claude Pache)
> Le 14 avr. 2020 à 16:54, Nicolas Grekas grekas+php@gmail.com> a écrit : > > I'm just not sold on allowing "void" on __construct, because the very concept of a return type on a constructor is ... void, and also because of the code style choices this will open (and the CS "wars" I mentioned). >
This issue is not specific to magic method like __construct(). It is the whole concept of “void” as return type which is, say, “problematic”. In fact, “void” is not really a return type. It is a way to state that the method is not supposed to return anything, which means, as you said very well, that “the very concept of return type on [this method] is void”. That might be a reason to reject the concept of “void” as return type. Or to revive https://wiki.php.net/rfc/allow-void-variance <https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is orthogonal to the fact that this particular method is magic, and we should not cherry-pick and reject the concept of “void” for __construct() and similar magic methods only. —Claude
  109638
April 14, 2020 16:53 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Apr 14, 2020 at 6:07 PM Claude Pache pache@gmail.com> wrote:

> > > > Le 14 avr. 2020 à 16:54, Nicolas Grekas grekas+php@gmail.com> > a écrit : > > > > I'm just not sold on allowing "void" on __construct, because the very > concept of a return type on a constructor is ... void, and also because of > the code style choices this will open (and the CS "wars" I mentioned). > > > > This issue is not specific to magic method like __construct(). It is the > whole concept of “void” as return type which is, say, “problematic”. > > In fact, “void” is not really a return type. It is a way to state that the > method is not supposed to return anything, which means, as you said very > well, that “the very concept of return type on [this method] is void”. > > That might be a reason to reject the concept of “void” as return type. Or > to revive https://wiki.php.net/rfc/allow-void-variance < > https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is > orthogonal to the fact that this particular method is magic, and we should > not cherry-pick and reject the concept of “void” for __construct() and > similar magic methods only.
Constructors not having a return type is standard behavior across most (all?) languages. You can't specify a constructor return type in C++. You can't specify one in C#. You can't specify one in Java. Off-hand, I can't name a language that both has a first-class constructor concept (Rust's "new" idiom does not count) and specifies a return type on it. It would naturally follow that, yes, you can't specify a constructor return type in PHP either, just like we enforce right now. Unless we have some strong reason to deviate from standard behavior that I do not see? Regards, Nikita
  109641
April 14, 2020 17:45 claude.pache@gmail.com (Claude Pache)
> Le 14 avr. 2020 à 18:53, Nikita Popov ppv@gmail.com> a écrit : > > On Tue, Apr 14, 2020 at 6:07 PM Claude Pache pache@gmail.com <mailto:claude.pache@gmail.com>> wrote: > > > > Le 14 avr. 2020 à 16:54, Nicolas Grekas grekas+php@gmail.com <mailto:nicolas.grekas%2Bphp@gmail.com>> a écrit : > > > > I'm just not sold on allowing "void" on __construct, because the very concept of a return type on a constructor is ... void, and also because of the code style choices this will open (and the CS "wars" I mentioned). > > > > This issue is not specific to magic method like __construct(). It is the whole concept of “void” as return type which is, say, “problematic”. > > In fact, “void” is not really a return type. It is a way to state that the method is not supposed to return anything, which means, as you said very well, that “the very concept of return type on [this method] is void”. > > That might be a reason to reject the concept of “void” as return type. Or to revive https://wiki.php.net/rfc/allow-void-variance <https://wiki.php.net/rfc/allow-void-variance> <https://wiki.php.net/rfc/allow-void-variance <https://wiki.php.net/rfc/allow-void-variance>> . But again, the issue is orthogonal to the fact that this particular method is magic, and we should not cherry-pick and reject the concept of “void” for __construct() and similar magic methods only. > > Constructors not having a return type is standard behavior across most (all?) languages. You can't specify a constructor return type in C++. You can't specify one in C#. You can't specify one in Java. Off-hand, I can't name a language that both has a first-class constructor concept (Rust's "new" idiom does not count) and specifies a return type on it. > > It would naturally follow that, yes, you can't specify a constructor return type in PHP either, just like we enforce right now. Unless we have some strong reason to deviate from standard behavior that I do not see? > > Regards, > Nikita
Do those languages allow to return something from the constructor (as does PHP currently)? because I’m more interested in the semantics of `: void` than the exact way to have it. —Claude
  109644
April 15, 2020 10:56 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Apr 14, 2020 at 7:45 PM Claude Pache pache@gmail.com> wrote:

> > > Le 14 avr. 2020 à 18:53, Nikita Popov ppv@gmail.com> a écrit : > > On Tue, Apr 14, 2020 at 6:07 PM Claude Pache pache@gmail.com> > wrote: > >> >> >> > Le 14 avr. 2020 à 16:54, Nicolas Grekas grekas+php@gmail..com> >> a écrit : >> > >> > I'm just not sold on allowing "void" on __construct, because the very >> concept of a return type on a constructor is ... void, and also because of >> the code style choices this will open (and the CS "wars" I mentioned). >> > >> >> This issue is not specific to magic method like __construct(). It is the >> whole concept of “void” as return type which is, say, “problematic”. >> >> In fact, “void” is not really a return type. It is a way to state that >> the method is not supposed to return anything, which means, as you said >> very well, that “the very concept of return type on [this method] is void”. >> >> That might be a reason to reject the concept of “void” as return type. Or >> to revive https://wiki.php.net/rfc/allow-void-variance < >> https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is >> orthogonal to the fact that this particular method is magic, and we should >> not cherry-pick and reject the concept of “void” for __construct() and >> similar magic methods only. > > > Constructors not having a return type is standard behavior across most > (all?) languages. You can't specify a constructor return type in C++. You > can't specify one in C#. You can't specify one in Java. Off-hand, I can't > name a language that both has a first-class constructor concept (Rust's > "new" idiom does not count) and specifies a return type on it. > > It would naturally follow that, yes, you can't specify a constructor > return type in PHP either, just like we enforce right now. Unless we have > some strong reason to deviate from standard behavior that I do not see? > > Regards, > Nikita > > > Do those languages allow to return something from the constructor (as does > PHP currently)? because I’m more interested in the semantics of `: void` > than the exact way to have it. >
Ah, so that's what this is about! In that case, I'd be happy to simply always enforce that __construct() cannot return a value, in the same way we do for ": void" functions. (If we have backwards compatibility concerns, we can add this as a warning instead of hard error.) Nikita
  109657
April 15, 2020 14:50 carusogabriel34@gmail.com (Gabriel Caruso)
On Wed, 15 Apr 2020 at 12:57, Nikita Popov ppv@gmail.com> wrote:

> On Tue, Apr 14, 2020 at 7:45 PM Claude Pache pache@gmail.com> > wrote: > >> >> >> Le 14 avr. 2020 à 18:53, Nikita Popov ppv@gmail.com> a écrit : >> >> On Tue, Apr 14, 2020 at 6:07 PM Claude Pache pache@gmail.com> >> wrote: >> >>> >>> >>> > Le 14 avr. 2020 à 16:54, Nicolas Grekas grekas+php@gmail.com> >>> a écrit : >>> > >>> > I'm just not sold on allowing "void" on __construct, because the very >>> concept of a return type on a constructor is ... void, and also because of >>> the code style choices this will open (and the CS "wars" I mentioned). >>> > >>> >>> This issue is not specific to magic method like __construct(). It is the >>> whole concept of “void” as return type which is, say, “problematic”. >>> >>> In fact, “void” is not really a return type. It is a way to state that >>> the method is not supposed to return anything, which means, as you said >>> very well, that “the very concept of return type on [this method] is void”. >>> >>> That might be a reason to reject the concept of “void” as return type. >>> Or to revive https://wiki.php.net/rfc/allow-void-variance < >>> https://wiki.php.net/rfc/allow-void-variance> . But again, the issue is >>> orthogonal to the fact that this particular method is magic, and we should >>> not cherry-pick and reject the concept of “void” for __construct() and >>> similar magic methods only. >> >> >> Constructors not having a return type is standard behavior across most >> (all?) languages. You can't specify a constructor return type in C++. You >> can't specify one in C#. You can't specify one in Java. Off-hand, I can't >> name a language that both has a first-class constructor concept (Rust's >> "new" idiom does not count) and specifies a return type on it. >> >> It would naturally follow that, yes, you can't specify a constructor >> return type in PHP either, just like we enforce right now. Unless we have >> some strong reason to deviate from standard behavior that I do not see? >> >> Regards, >> Nikita >> >> >> Do those languages allow to return something from the constructor (as >> does PHP currently)? because I’m more interested in the semantics of `: >> void` than the exact way to have it. >> > > Ah, so that's what this is about! In that case, I'd be happy to simply > always enforce that __construct() cannot return a value, in the same way we > do for ": void" functions. (If we have backwards compatibility concerns, we > can add this as a warning instead of hard error.) > > Nikita >
I'll change the RFC and remove the `: void` return allowance for `__construct()`. Should we do the same for `__destruct()`? Nikita, about your suggestion of checking the actual return value of `__construct()`, I've mentioned in the RFC that I want to do that for all the magic methods in a future RFC ( https://wiki.php.net/rfc/magic-methods-signature#future-scope). Do you think we can follow with that, or no, we should add this check to the current RFC? Nicolas, I've improved the RFC document. Let me know if there's anything else that I need to clarify. Thanks for the feedback y'all. Best regards,
  109691
April 16, 2020 16:46 tysonandre775@hotmail.com (tyson andre)
> Ah, so that's what this is about! In that case, I'd be happy to simply > always enforce that __construct() cannot return a value, in the same way we > do for ": void" functions. (If we have backwards compatibility concerns, we > can add this as a warning instead of hard error.)
I'd approve of that. It'd also be useful to enforce that __construct and other magic methods aren't generators, and that methods from traits renamed to __construct have the same restrictions. ``` php > class X{ public function __construct() { yield 2; }} php > new X(); // nonsense php > trait T1 { public function f() { echo "In f\n"; return 2; }} php > class Z { use T1{ f as __construct; } } php > new Z(); In f ``` - Tyson
  109811
April 23, 2020 14:07 carusogabriel34@gmail.com (Gabriel Caruso)
On Thu, 16 Apr 2020 at 18:46, tyson andre <tysonandre775@hotmail.com> wrote:

> > Ah, so that's what this is about! In that case, I'd be happy to simply > > always enforce that __construct() cannot return a value, in the same way > we > > do for ": void" functions. (If we have backwards compatibility concerns, > we > > can add this as a warning instead of hard error.) > > I'd approve of that. It'd also be useful to enforce that __construct and > other magic methods aren't generators, > and that methods from traits renamed to __construct have the same > restrictions. > > ``` > php > class X{ public function __construct() { yield 2; }} > php > new X(); // nonsense > php > trait T1 { public function f() { echo "In f\n"; return 2; }} > php > class Z { use T1{ f as __construct; } } > php > new Z(); > In f > ``` > > - Tyson
Hello Tyson, This falls under the `Future Scope` of the RFC ( https://wiki.php.net/rfc/magic-methods-signature#future-scope) as checking for the actual return value of these magic methods would be a larger BC. For now, only the signatures will be checked.
  109672
April 15, 2020 22:26 carusogabriel34@gmail.com (Gabriel Caruso)
On Sun, 5 Apr 2020 at 16:01, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> > Hello, internals. > > Hereby you can find the RFC Document that I want to discuss as suggested > via https://externals.io/message/109416 and > https://externals.io/message/107990: > > https://wiki.php.net/rfc/magic-methods-signature > > Best regards, > > -- Gabriel Caruso >
As suggested by Mr. Danack, I've added a section to the RFC: `RFC Impact`, which lists the cases that would break with this RFC. Thanks for the suggestion, sir.
  109686
April 16, 2020 14:22 guilliam.xavier@gmail.com (Guilliam Xavier)
On Sun, Apr 5, 2020 at 4:02 PM Gabriel Caruso <carusogabriel34@gmail.com> wrote:
> > Hello, internals. > > Hereby you can find the RFC Document that I want to discuss as suggested > via https://externals.io/message/109416 and > https://externals.io/message/107990: > > https://wiki.php.net/rfc/magic-methods-signature > > Best regards, > > -- Gabriel Caruso
Hello, Thank you, this seems a sensible thing to add. Just an interrogation: the following magic methods (from the documentation) aren't mentioned at all in the RFC: - `__sleep(): array` - `__wakeup(): void` - `__unserialize(array $data): void` - (`__invoke` is basically untyped) - `__set_state(array $properties): object` - `__debugInfo(): array` Is there a reason for leaving them out? Related, the RFC mentions that `__serialize` and `__toString` already have a *runtime* check that they respectively return an `array` and a `string` (when called), but why not check their signature (if typed) at *compile time* too (i.e. make https://3v4l.org/ZPrVi an error)? Regards, -- Guilliam Xavier
  109690
April 16, 2020 15:24 carusogabriel34@gmail.com (Gabriel Caruso)
On Thu, 16 Apr 2020 at 16:22, Guilliam Xavier xavier@gmail.com>
wrote:

> On Sun, Apr 5, 2020 at 4:02 PM Gabriel Caruso <carusogabriel34@gmail.com> > wrote: > > > > Hello, internals. > > > > Hereby you can find the RFC Document that I want to discuss as suggested > > via https://externals.io/message/109416 and > > https://externals.io/message/107990: > > > > https://wiki.php.net/rfc/magic-methods-signature > > > > Best regards, > > > > -- Gabriel Caruso > > Hello, > > Thank you, this seems a sensible thing to add. > > Just an interrogation: the following magic methods (from the > documentation) aren't mentioned at all in the RFC: > - `__sleep(): array` > - `__wakeup(): void` > - `__unserialize(array $data): void` > - (`__invoke` is basically untyped) > - `__set_state(array $properties): object` > - `__debugInfo(): array` > Is there a reason for leaving them out? > Related, the RFC mentions that `__unserialize` and `__toString` already > have a *runtime* check that they respectively return an `array` and a > `string` (when called), but why not check their signature (if typed) > at *compile time* too (i.e. make https://3v4l.org/ZPrVi an error)? > > Regards, > > -- > Guilliam Xavier >
Hello Guilliam Magic methods not mentioned in the RFC won't be changed, that's why they aren't mentioned. The reason is either: - Isn't possible to add checks: the case of `__invoke` - They aren't really magic methods, but an extension method implementation (as far as I understood during the development of this RFC) `__unserialize` and `__serialize` should be possible to add these checks, I'll take a look in the implementation. About `__toString`: this check is already performed in PHP 8.0: https://3v4l.org/jIg7b/rfc#git-php-maste <https://3v4l.org/jIg7b/rfc#git-php-master>r
  109889
April 28, 2020 16:31 carusogabriel34@gmail.com (Gabriel Caruso)
On Thu, 16 Apr 2020 at 16:22, Guilliam Xavier xavier@gmail.com>
wrote:

> On Sun, Apr 5, 2020 at 4:02 PM Gabriel Caruso <carusogabriel34@gmail.com> > wrote: > > > > Hello, internals. > > > > Hereby you can find the RFC Document that I want to discuss as suggested > > via https://externals.io/message/109416 and > > https://externals.io/message/107990: > > > > https://wiki.php.net/rfc/magic-methods-signature > > > > Best regards, > > > > -- Gabriel Caruso > > Hello, > > Thank you, this seems a sensible thing to add. > > Just an interrogation: the following magic methods (from the > documentation) aren't mentioned at all in the RFC: > - `__sleep(): array` > - `__wakeup(): void` > - `__unserialize(array $data): void` > - (`__invoke` is basically untyped) > - `__set_state(array $properties): object` > - `__debugInfo(): array` > Is there a reason for leaving them out? > Related, the RFC mentions that `__serialize` and `__toString` already > have a *runtime* check that they respectively return an `array` and a > `string` (when called), but why not check their signature (if typed) > at *compile time* too (i.e. make https://3v4l.org/ZPrVi an error)? > > Regards, > > -- > Guilliam Xavier >
The RFC has been updated with the missing methods. If there are no further requests or comments, I'll open this RFC for voting next Friday.
  109950
April 30, 2020 23:47 Danack@basereality.com (Dan Ackroyd)
On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso <carusogabriel34@gmail.com> wrote:
> > If there are no further requests or comments, I'll open this RFC for voting > next Friday.
Hi Gabriel, I think it would be better to hold off until the mixed RFC has been voted on. If that passes, the four signatures that still have mixed in the docblock, could be updated to use mixed in the actual signature. There's plenty of time until the release process starts. cheers Dan Ack
  109951
May 1, 2020 11:06 carusogabriel34@gmail.com (Gabriel Caruso)
On Fri, 1 May 2020 at 01:47, Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso <carusogabriel34@gmail.com> > wrote: > > > > If there are no further requests or comments, I'll open this RFC for > voting > > next Friday. > > Hi Gabriel, > > I think it would be better to hold off until the mixed RFC has been voted > on. > > If that passes, the four signatures that still have mixed in the > docblock, could be updated to use mixed in the actual signature. > > There's plenty of time until the release process starts. > > cheers > Dan > Ack >
Hello sir. I'll hold to start the voting process for this one until https://wiki.php.net/rfc/mixed_type_v2 gets discussed and voted, no problems. Thanks for the head up. Best regards,
  110277
May 26, 2020 13:56 carusogabriel34@gmail.com (Gabriel Caruso)
On Fri, 1 May 2020 at 13:06, Gabriel Caruso <carusogabriel34@gmail.com>
wrote:

> On Fri, 1 May 2020 at 01:47, Dan Ackroyd <Danack@basereality.com> wrote: > >> On Tue, 28 Apr 2020 at 17:32, Gabriel Caruso <carusogabriel34@gmail.com> >> wrote: >> > >> > If there are no further requests or comments, I'll open this RFC for >> voting >> > next Friday. >> >> Hi Gabriel, >> >> I think it would be better to hold off until the mixed RFC has been voted >> on. >> >> If that passes, the four signatures that still have mixed in the >> docblock, could be updated to use mixed in the actual signature. >> >> There's plenty of time until the release process starts. >> >> cheers >> Dan >> Ack >> > > Hello sir. > > I'll hold to start the voting process for this one until > https://wiki.php.net/rfc/mixed_type_v2 gets discussed and voted, no > problems. > > Thanks for the head up. > > Best regards, >
Alright, `mixed` type RFC voted and merged, time to move with this one. We still got time, so I'll wait until this Friday (29/05) to start the voting, if someone still has any objections or questions regarding this RFC. -- Gabriel Caruso