> As a special-case, quoted strings show the string's *content* in double
> quotes, e.g. 'unexpected quoted string "foo" ...' rather than 'unexpected
> quoted string ""foo"" ...' or 'unexpected quoted string "'foo'" ...'.
For me, in this case, you have dropped the wrong pair of quotes. That i
Nicely done.
No need for an RFC.
Thanks.
On Sunday, 28 June 2020, Stanislav Malyshev wrote:
> Hi!
>
> > For more examples, see:
> > https://rwec.co.uk/x/php-parse-errors/comparison.html
> >
> > The patch can be reviewed at: https://github.com/php/php-src/pull/5722
>
> I think this is great, th
Hi!
> For more examples, see:
> https://rwec.co.uk/x/php-parse-errors/comparison.html
>
> The patch can be reviewed at: https://github.com/php/php-src/pull/5722
I think this is great, thanks for implementing it!
> I am happy to post a small RFC if people think this requires a vote.
>
> Any oth
Hi all,
During the discussion of "T_PAAMAYIM_NEKUDOTAYIM", there was broad
agreement that internal token names should not be included in errors
shown to users. I now have an implementation of this.
Note that we currently only customise the token descriptions placed into
Bison's hard-coded te
Am 28.06.2020 um 14:35 schrieb Nikita Popov:
I do support allowing types for class constants in the interest of overall
language consistency.
Same here: +1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 27/06/2020 23:53, G. P. B. wrote:
[...] there are only 3 parse errors which have the added
information of what the token represents, namely T_SL, T_SR, and
T_PAAMAYIM_NEKUDOTAYIM.
I'm not sure what you mean by there being only three. Since PHP 5.4, all
parser errors include the content of
On Fri, Jun 26, 2020 at 8:45 AM Alex wrote:
> Dear PHP Internals,
>
> I would like to propose a backwards-incompatible change to
> SplFixedArray which fixes the strange and almost certainly unintended
> behavior reported in Bug 79404
> (https://bugs.php.net/bug.php?id=79404).
>
> In short: Becaus
On Sun, Jun 28, 2020 at 2:03 PM Benas IML wrote:
> Hey internals,
>
> Is there any particular reason as to why constants cannot be typed? For
> example:
>
> ```
> class Test {
> // this is illegal
> public const int TEST = 1;
> }
> ```
>
> Having typed constants would be quite ben
On Sat, Jun 27, 2020 at 3:53 PM Stephen Reay
wrote:
> Hi,
>
> It’s always struck me as slightly odd that traits don’t support constants
> the way classes and interfaces do.
> I tried to find an explanation of the lack of support in the original RFC,
> and came up empty.
>
> A consequent discussio
Hey internals,
Is there any particular reason as to why constants cannot be typed? For example:
```
class Test {
// this is illegal
public const int TEST = 1;
}
```
Having typed constants would be quite beneficial. First of all, we
would obviously be more consistent with properti
10 matches
Mail list logo
