Le jeudi 20 juin 2024, 19:38:40 UTC+2 Larry Garfield a écrit :
> To that end, we're looking for *very high level* feedback on this RFC:
>
> https://wiki.php.net/rfc/pattern-matching
Hello,
Thank you for this RFC.
Sorry if that’s a bit focused on syntax, but I’m really concerned by the
binding
> $p is Point {x: 3, y: $y};
> // If $p->x === 3, bind $p->y to $y and return true.
> $p is Point {y: 37, x:@($x)};
> // $p->x === $x && $p->y == 37
I'm just going to put in my $0.02 here and downvote this syntax. I
believe that it should be swapped. IMO, `{x: 3, y: $y}` looks too
similar to the
On Wed, Jun 26, 2024, at 23:42, Ilija Tovilo wrote:
>
> function test($value) {
> if ($value is ['foo' => ?string]) {
> $foo = $value['foo'];
> }
> }
> test([]);
(Scroll to the end if you don’t care about my rebuttal)
I mean, there’s nothing wrong with this code, $foo will be nul
On 2024-06-27 12:41, Chuck Adams wrote:
There’s some difference though
[] is [?’foo’ => $x is string] // matches, $x === null
Except null is not a string.
> There’s a precedent with function parameters:
>
> function foo(string $bar = null) // $bar is string|null
>
whi
> On Jun 26, 2024, at 1:50 PM, Morgan wrote:
> So the issue has nothing to do with this hypothetical infinity of
> unobservable nulls, and comes entirely down to the fact that with this
> pattern a variable may pass
> a) because it does not have a key named 'foo', or
> b) because it has a key na
Hi Rob
On Wed, Jun 26, 2024 at 10:36 PM Rob Landers wrote:
>
>> On Wed, Jun 26, 2024, at 21:50, Morgan wrote:
>>
>> So the issue has nothing to do with this hypothetical infinity of
>> unobservable nulls, and comes entirely down to the fact that with this
>> pattern a variable may pass
>> a) beca
I wonder if this could be helpful in implementing Generic Classes?
https://wiki.php.net/rfc/generics
Interface Boxable {...}
class Box {...}
Taken from the RFC ^
Best,
Richard Miles
On Wed, Jun 26, 2024, at 21:50, Morgan wrote:
> On 2024-06-26 09:58, Rob Landers wrote:
> > On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
> >>
> >>
> >> It may be questionable to give meaning to the difference in some of
> >> these cases, but different it definitely is.
> >
> > Tru
On 2024-06-26 09:58, Rob Landers wrote:
On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
It may be questionable to give meaning to the difference in some of
these cases, but different it definitely is.
True, but I was mainly referring to what you would do after performing
an 'i
On Wed, Jun 26, 2024, at 19:57, Richard Miles wrote:
> “Array-application will also be pushed to future-scope”
>
>
> Dang, this is what I was looking forward to the most. Helping set some
> precedent on this issue, and this is a solid start. I’ve been thinking about
> what it would look like fo
After a coffee break, I think this is how the language could do this in a
semantically pleasing way.
interface iArrayA ['a' => string ]
interface iArrayB extends iArrayA ['b' => string ]
$arr is iArrayA &| iArrayB
Best,
Richard Miles
> On Jun 26, 2024, at 11:57 AM, Richard Miles wrote:
>
>
“Array-application will also be pushed to future-scope”
Dang, this is what I was looking forward to the most. Helping set some
precedent on this issue, and this is a solid start. I’ve been thinking about
what it would look like for strictly typed arrays in PHP for a while now. I
think a custom
On 26 June 2024 09:23:42 BST, Rob Landers wrote:
>
>It will always output that warning, regardless of strict types, but as this
>thread has already covered numerous times, it is unobservable from the
>executing code unless you turn the warning into an exception.
I think this conversation is
On Wed, Jun 26, 2024, at 10:11, Arvids Godjuks wrote:
>
>
> On Wed, 26 Jun 2024 at 11:00, Rob Landers wrote:
>> __
>>
>>
>> On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote:
>>>
>>>
>>> On Wed, Jun 26, 2024, at 00:19, Morgan wrote:
On 2024-06-26 08:24, Rob Landers wrote:
> On Tu
On Wed, 26 Jun 2024 at 11:00, Rob Landers wrote:
>
>
> On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote:
>
>
>
> On Wed, Jun 26, 2024, at 00:19, Morgan wrote:
>
> On 2024-06-26 08:24, Rob Landers wrote:
> > On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
>
> >> If null array values were inde
On Wed, Jun 26, 2024, at 09:54, Rob Landers wrote:
>
>
> On Wed, Jun 26, 2024, at 00:19, Morgan wrote:
>> On 2024-06-26 08:24, Rob Landers wrote:
>> > On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
>>
>> >> If null array values were indeed unobservable, then [] would be === to
>> >> [null
On Wed, Jun 26, 2024, at 00:19, Morgan wrote:
> On 2024-06-26 08:24, Rob Landers wrote:
> > On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
>
> >> If null array values were indeed unobservable, then [] would be === to
> >> [null] (or at least ==), and a foreach over [null] would result in 0
On 2024-06-26 08:24, Rob Landers wrote:
On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
If null array values were indeed unobservable, then [] would be === to
[null] (or at least ==), and a foreach over [null] would result in 0
iterations. But neither of those are the case.
I think there
On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
>
>
> On 25 June 2024 21:24:32 BST, Rob Landers wrote:
> >The only way you’d observe this (that I can think of) is by performing a
> >for-each loop over the array.
>
> There are many ways you can observe the difference between an ab
On 25 June 2024 21:24:32 BST, Rob Landers wrote:
>The only way you’d observe this (that I can think of) is by performing a
>for-each loop over the array.
There are many ways you can observe the difference between an absent key and a
null value; here are just a handful off the top of my head
On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
> Hi Rob
>
> On Tue, Jun 25, 2024 at 9:05 AM Rob Landers wrote:
> >
> > On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:
> >
> > On Mon, Jun 24, 2024 at 9:54 PM Robert Landers
> > wrote:
> > >
> > > To be honest, this is one of the smaller
Hi Rob
On Tue, Jun 25, 2024 at 9:05 AM Rob Landers wrote:
>
> On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:
>
> On Mon, Jun 24, 2024 at 9:54 PM Robert Landers
> wrote:
> >
> > To be honest, this is one of the smaller concerns I have with the new
> > syntax. There might be some misundersta
On Mon, 24 Jun 2024, Larry Garfield wrote:
> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
>
> * The placement of `is` on `match()` is still an open question.
"The latter is more explicit, and would allow individual arms to be
pattern matched or not depending on the presence of is."
On Tue, Jun 25, 2024 at 9:44 AM Robert Landers
wrote:
> On Tue, Jun 25, 2024 at 2:48 AM Larry Garfield
> wrote:
> >
> > On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
> >
> > > To that end, we're looking for *very high level* feedback on this RFC:
> > >
> > > https://wiki.php.net/rfc/pa
On Tue, Jun 25, 2024 at 2:48 AM Larry Garfield wrote:
>
> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
>
> > To that end, we're looking for *very high level* feedback on this RFC:
> >
> > https://wiki.php.net/rfc/pattern-matching
>
> Hi folks. Thank you to those who have offered feedba
On 25 June 2024 00:31:56 BST, Larry Garfield wrote:
>
>* There's not been much discussion of range patterns. Anyone want to weigh in
>on those?
I didn't even notice them until someone else mentioned some detail of the
syntax.
Like regex patterns and the generic-like array syntax, they loo
On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:
> On Mon, Jun 24, 2024 at 9:54 PM Robert Landers
> wrote:
> >
> > > The first means b is an optional key, but if it’s there, can only be a
> > > string. The second says b is a required key, but it may be a string or
> > > null. If there were
On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
> To that end, we're looking for *very high level* feedback on this RFC:
>
> https://wiki.php.net/rfc/pattern-matching
Hi folks. Thank you to those who have offered feedback so far. Based on the
discussion, here's what we're thinking of d
On Mon, Jun 24, 2024 at 9:54 PM Robert Landers wrote:
>
> > The first means b is an optional key, but if it’s there, can only be a
> > string. The second says b is a required key, but it may be a string or
> > null. If there were a binding involved, that determines the type of the
> > binding i
> On Jun 24, 2024, at 1:53 PM, Robert Landers wrote:
>
> $arr = ['a' => 'a string'];
> $arr is ['a' => string, ?'b' => $value, ...];
>
> This syntax implies that a non-existent key is a special case, and if
> it passes as-is, it will be. If there is a binding and the key is
> missing, what happens
On Mon, Jun 24, 2024 at 7:28 PM Chuck Adams wrote:
>
>
> > On Jun 24, 2024, at 3:31 AM, Robert Landers
> > wrote:
> >
> >
> > There's no need to use `?` to check for existence on a key, so this:
> >
> > $arr is ['a' => string, ?'b' => string, ...];
> >
> > should be this:
> >
> > $arr is ['a' =>
> On Jun 24, 2024, at 3:31 AM, Robert Landers wrote:
>
>
> There's no need to use `?` to check for existence on a key, so this:
>
> $arr is ['a' => string, ?'b' => string, ...];
>
> should be this:
>
> $arr is ['a' => string, 'b' => ?string, ...];
>
> because $arr['non-existent-key'] is NU
On Mon, Jun 24, 2024 at 7:04 AM Hendra Gunawan
wrote:
>
> I agree that this proposal should be proposed as a whole. If we break
> it down into smaller parts, there is a chance some features will not
> pass.
This is exactly my concern and I fear we will be dealing with the
repercussions of a non-w
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations. A number of people have noticed and said
> they're looking forward to it.
[THIS REPLY IS FOR THE CONVENIENCE OF https://externals.io READERS
ONLY. SORRY FOR THE UNPLEASANT DISPLAY]
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations. A number of people have noticed and said
> they're looking forward to it.
Hello Larry.
Thanks for this Juicy proposal.
I agree that this proposal should be proposed as a whole. If
On Sun, Jun 23, 2024, at 2:14 PM, Andreas Hennings wrote:
> This leads me to a different question regarding property guards.
> What if we validate an object property guard, which later changes?
>
> class C {
> public function __construct(
> public readonly Point $point is Point { $z: 0 };
>
On Sun, 23 Jun 2024 at 18:28, Larry Garfield wrote:
>
> On Thu, Jun 20, 2024, at 8:35 PM, Andreas Hennings wrote:
> >> Ilija and I have been working on and off on an RFC for pattern matching
> >> since the early work on Enumerations.
> >
> > I like what I see, a lot!
> > One quick thought that ca
On Sun, Jun 23, 2024 at 2:19 PM Rowan Tommins [IMSoP]
wrote:
>
>
>
> On 22 June 2024 22:57:24 BST, Robert Landers wrote:
> >In general, you assign the result of the operation so that the output
> >is useful. Here's how that might look in PHP with the C# rules:
> >
> >function foo(BarInterface $ba
On Thu, Jun 20, 2024, at 8:35 PM, Andreas Hennings wrote:
>> Ilija and I have been working on and off on an RFC for pattern matching
>> since the early work on Enumerations.
>
> I like what I see, a lot!
> One quick thought that came to my mind, regarding objects:
> Could we check method return va
On Sat, Jun 22, 2024, at 12:14 PM, Brandon Jackson wrote:
>> To clarify here, these all come as a set. Array shapes aren't their own
>> "thing", they just fall out naturally from array patterns. So it's not
>> possible for associative patterns to conflict with array shapes, as they are
>> lit
On Sat, Jun 22, 2024, at 12:43 AM, Robert Landers wrote:
> Sorry, I wasn't exactly clear what I meant on scope. I wasn't
> necessarily meaning the feature/RFC, but rather the scope of the
> conversation. I count at least 12 new types of syntax here (possibly
> more that I missed), and I would be s
On 22 June 2024 22:57:24 BST, Robert Landers wrote:
>In general, you assign the result of the operation so that the output
>is useful. Here's how that might look in PHP with the C# rules:
>
>function foo(BarInterface $bar) {
> $baz = $bar as Baz;
> $baz?->thing();
> $bar->otherThing();
>}
On Sat, Jun 22, 2024 at 11:57 PM Robert Landers
wrote:
>
> On Sat, Jun 22, 2024 at 10:53 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 22/06/2024 19:34, Robert Landers wrote:
> >
> > I've brought this up before, but I mostly see "as" being useful for
> > static analysis. That's what I've mostly us
On Sat, Jun 22, 2024 at 10:53 PM Rowan Tommins [IMSoP]
wrote:
>
> On 22/06/2024 19:34, Robert Landers wrote:
>
> I've brought this up before, but I mostly see "as" being useful for
> static analysis. That's what I've mostly used it for C#, anyway.
> Logically, you know the type, but due to one-thi
On 22/06/2024 21:15, Robert Landers wrote:
To me, that sounds kinda silly. PHP does reference counting and while
there is an overhead, it doesn't prevent us from using it...
The reference count is a single pre-allocated integer on the C struct
holding the value; and even then, a lot of effort
On Sat, Jun 22, 2024 at 8:59 PM Arnaud Le Blanc wrote:
>
> On Fri, Jun 21, 2024 at 7:20 PM Robert Landers
> wrote:
> > > > I'm always surprised why arrays can't keep track of their internal
> > > > types. Every time an item is added to the map, just chuck in the type
> > > > and a count, then if
On Sat, Jun 22, 2024 at 10:16 AM Brandon Jackson wrote:
> > > 8. Capturing values out of a pattern and binding them to variables if
> > > matched
> > > Ok I think that's stepping a bit far out of scope. Maybe `is` should
> > > simply check and not have any side effects.
> >
> > As above, this is
On 22/06/2024 19:34, Robert Landers wrote:
I've brought this up before, but I mostly see "as" being useful for
static analysis. That's what I've mostly used it for C#, anyway.
Logically, you know the type, but due to one-thing-or-another you
can't "prove" the type is that type (such as foreach-ar
On Fri, Jun 21, 2024 at 7:20 PM Robert Landers
wrote:
> > > I'm always surprised why arrays can't keep track of their internal
> > > types. Every time an item is added to the map, just chuck in the type
> > > and a count, then if it is removed, decrement the counter, and if
> > > zero, remove the
On Sat, Jun 22, 2024 at 8:34 PM Robert Landers wrote:
>
> On Sat, Jun 22, 2024 at 8:04 PM Rowan Tommins [IMSoP]
> wrote:
> >
> > On 21/06/2024 19:29, Larry Garfield wrote:
> >
> > Valid points. The line between validation and casting is a bit squishy,
> > as some casts can be forced (eg, string
On Sat, Jun 22, 2024 at 8:04 PM Rowan Tommins [IMSoP]
wrote:
>
> On 21/06/2024 19:29, Larry Garfield wrote:
>
> Valid points. The line between validation and casting is a bit squishy,
> as some casts can be forced (eg, string to int gives 0 sometimes), and
> others just cannot (casting to an obj
On Fri, Jun 21, 2024 at 1:22 PM Larry Garfield wrote:
>
> To give more context, as noted, this is a stepping stone toward ADTs.
> Anything that is on the "hot path" for ADT support I would consider
> mandatory, so trying to split it up will just take more time and effort.
> That includes the
On 21/06/2024 19:03, Larry Garfield wrote:
* Regex pattern
This one is interesting as well ... but I would expect native regex
syntax first before introducing it as part of a different RFC. Similar
as generics.
Named capture groups are already part of regex syntax, just not often used.
The ex
On 21/06/2024 19:29, Larry Garfield wrote:
Valid points. The line between validation and casting is a bit squishy,
as some casts can be forced (eg, string to int gives 0 sometimes), and
others just cannot (casting to an object). So would $a as
array<~int> be casting, validating, or both?
I
On Sat, Jun 22, 2024 at 4:38 AM Gina P. Banyard wrote:
>
> On Friday, 21 June 2024 at 23:58, Robert Landers
> wrote:
> > As a user of PHP, this statement concerns me. I don't want any
> > features rushed just because someone wants it "now" and thus end up
> > with something feeling half-baked, m
On Friday, 21 June 2024 at 23:58, Robert Landers
wrote:
> As a user of PHP, this statement concerns me. I don't want any
> features rushed just because someone wants it "now" and thus end up
> with something feeling half-baked, missing important features or not
> completely thought through. I thi
On Friday, 21 June 2024 at 19:19, Larry Garfield wrote:
> On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote:
> > 4. Object matching
> > Absolutely a separate rfc please. Definitely needs discussion. Could
> > intersect another potentially preferred solution like type aliases.
> > Sending one
On Fri, Jun 21, 2024 at 9:33 PM Larry Garfield wrote:
>
> On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote:
> >> Ilija and I have been working on and off on an RFC for pattern matching
> >> since the early work on Enumerations. A number of people have noticed and
> >> said they're lookin
On 21 June 2024 19:29:19 BST, Larry Garfield wrote:
>
>We *still* have different implicit coercion rules?
I think Gina counted 10 contexts which behave slightly differently...
Regards,
--
Rowan Tommins
[IMSoP]
On Fri, Jun 21, 2024, at 12:38 PM, Rowan Tommins [IMSoP] wrote:
> On Thu, 20 Jun 2024, at 18:38, Larry Garfield wrote:
>> Hello, peoples.
>>
>> Ilija and I have been working on and off on an RFC for pattern matching
>> since the early work on Enumerations. A number of people have noticed
>> and
On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote:
>> Ilija and I have been working on and off on an RFC for pattern matching
>> since the early work on Enumerations. A number of people have noticed and
>> said they're looking forward to it.
>
> Hi Larry, I have definitely been looking for
On Fri, Jun 21, 2024, at 3:57 PM, Marc Bennewitz wrote:
>> Thank you all for your participation.
> Is is already a really nice RFC, even if not finished yet. Also haven't
> fully read it yet.
> Thank you for all your work and time put into it!
>
> I do have some questions:
>
> * For the generics
On Fri, Jun 21, 2024 at 6:58 PM Niels Dossche wrote:
>
> On 21/06/2024 14:43, Robert Landers wrote:
> > On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings
> > wrote:
> >>
> >>> Ilija and I have been working on and off on an RFC for pattern matching
> >>> since the early work on Enumerations.
> >>
> On Jun 21, 2024, at 11:42, Niels Dossche wrote:
>
> On 21/06/2024 14:43, Robert Landers wrote:
>> On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings wrote:
>>>
>>> E.g. should something like array be added to the type system in
>>> the future, or do we leave the type system behind, and rely
Hi Larry,
On 20.06.24 19:38, Larry Garfield wrote:
Hello, peoples.
Ilija and I have been working on and off on an RFC for pattern matching since
the early work on Enumerations. A number of people have noticed and said
they're looking forward to it.
It's definitely not going to make it into
On 21/06/2024 14:43, Robert Landers wrote:
> On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings wrote:
>>
>>> Ilija and I have been working on and off on an RFC for pattern matching
>>> since the early work on Enumerations.
>>
>> I like what I see, a lot!
>> One quick thought that came to my mind,
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations. A number of people have noticed and said
> they're looking forward to it.
Hi Larry, I have definitely been looking forward to this. Perhaps more
so than property hooks and avis.
>
On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings wrote:
>
> > Ilija and I have been working on and off on an RFC for pattern matching
> > since the early work on Enumerations.
>
> I like what I see, a lot!
> One quick thought that came to my mind, regarding objects:
> Could we check method return
On Thu, 20 Jun 2024, at 18:38, Larry Garfield wrote:
> Hello, peoples.
>
> Ilija and I have been working on and off on an RFC for pattern matching
> since the early work on Enumerations. A number of people have noticed
> and said they're looking forward to it.
Hi Larry,
I haven't time to read
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations.
I like what I see, a lot!
One quick thought that came to my mind, regarding objects:
Could we check method return values?
if ($x is Countable { count(): 0 }) ...
if ($p is Point { ge
On 2024-06-21 05:38, Larry Garfield wrote:
Hello, peoples.
To that end, we're looking for *very high level* feedback on this RFC:
https://wiki.php.net/rfc/pattern-matching
As I started reading I starting thinking of "whatabouts" based on my
experience with pattern matching in other language
This definitely looks like a powerful feature I'm looking forward to.
If property/param/return guards are implemented, do you see them eventually
replacing the property/param/return types we have nowadays?
Asking for a friend.
On Thu, Jun 20, 2024, at 8:29 PM, Thomas Bley wrote:
>> https://wiki.php.net/rfc/pattern-matching
> Thank you!
>
>> $var is *; // Matches anything, more useful in the structure patterns below.
>
> maybe also consider:
>
> $var is mixed; // Matches anything, more useful in the structure patterns
>
On Thu, Jun 20, 2024, at 8:22 PM, Lynn wrote:
> On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield wrote:
>> https://wiki.php.net/rfc/pattern-matching
> I have been looking forward to this RFC, it's such a quality of life to
> be able to do all this! In terms of things to focus on, I'd personally
> Larry Garfield hat am 20.06.2024 19:38 CEST
> geschrieben:
>
>
> Hello, peoples.
>
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations. A number of people have noticed and said
> they're looking forward to it.
>
> It's definitely
On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield
wrote:
> Hello, peoples.
>
> Ilija and I have been working on and off on an RFC for pattern matching
> since the early work on Enumerations. A number of people have noticed and
> said they're looking forward to it.
>
> It's definitely not going to m
OMG, this RFC is a true masterpiece!!!
Congratulations, it turned out really well! I hope this gets approved soon!
Rodrigo A. Vieira
Em 20 de jun. de 2024, 15:03 -0300, Eugene Sidelnyk ,
escreveu:
> You won't believe it, but just right now I've been thinking about that it
> would be a wonderful
You won't believe it, but just right now I've been thinking about that it
would be a wonderful feature for PHP to have some kind of type-tests (like
`$a is Foo&Bar` or `$b is Foo|Baz|null`), and here you write out this email.
I didn't read the whole RFC, but I'd like to say that having at least
af
Hello, peoples.
Ilija and I have been working on and off on an RFC for pattern matching since
the early work on Enumerations. A number of people have noticed and said
they're looking forward to it.
It's definitely not going to make it into 8.4, but we are looking for early
feedback on scoping
79 matches
Mail list logo
