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

> Le 26 sept. 2019 à 11:21, Lynn a écrit : > > > I'm not sure this type should be declarable in user-land, meaning it's > limited to the core and a marker for legacy. In general, we should avoid to give builtin code functionality that can’t be reproduced in userland, unless there is a good

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

> Le 23 sept. 2019 à 22:14, Benjamin Morel a écrit : > > > So although true as a type does not have the same historical background as > false, it does seem that it's being used by enough packages to be worth > considering; what do you think? > Considering to support `true` will raise severa

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

> Le 18 sept. 2019 à 18:28, Nikita Popov a écrit : > > I just realized that I missed one notice here, because it is generated from > a different location: "Constant %s already defined" (The define/const will > be ignored and the previous value used.) > > It would be great to have that as an e

Re: [PHP-DEV] Evolving PHP

> Le 16 sept. 2019 à 21:32, Nikita Popov a écrit : > > * Discussion threads on this mailing list have been very unpleasant > recently. I am unwilling to actively participate in them in this form. This > is bad for everyone, but particularly for opponents of proposals. It means > that we cannot

Re: [PHP-DEV] [RFC] Object Initializer

> Le 13 sept. 2019 à 07:49, Michał Brzuchalski a > écrit : > > Hi Lynn, > > czw., 12 wrz 2019 o 17:01 Lynn mailto:kja...@gmail.com>> > napisał(a): > >> Heya, >> >> What's the added benefit of this compared to implementing a constructor? >> >> The part I like is that this can be used to re

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 12 sept. 2019 à 15:33, Marco Pivetta a écrit : > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1; > > Marco Pivetta That violates blatantly DRY (twice the exact same lengthy expression `$foo[$key1][$key2]`), so it is not a satisfactory solution. —Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 12 sept. 2019 à 10:17, Stephen Reay a écrit : > > > > I’ve seen a number of people that have concerns about PHP throwing actual > errors (as opposed to notices) because they try to use a variable/offset that > doesn’t exist, and of course there is often a proposal to have a declare >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 10 sept. 2019 à 15:31, Nikita Popov a écrit : > > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > >> Hi internals, >> >> I think it's time to take a look at our existing warnings & notices in the >> engine, and think about whether their current classification is still >> appropriat

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

> 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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 29 août 2019 à 18:25, Aegir Leet a écrit : > > Either way, if you want a less strict language, that language already > exists: It's the current version of PHP and you and everyone else who > likes the way it works can keep using it. > Meanwhile, I think most people currently doing serious

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 29 août 2019 à 18:13, Matthew Brown a écrit : > > I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used > today mostly as its architect intended at its founding. PHP, having > transitioned from a templating system to a fully-fledged language, is used > quite differen

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> Le 29 août 2019 à 13:33, Aegir Leet via internals a > écrit : > > I'm sorry, but if you seriously believe doing something that generates a > notice (or warning, or error, ...) is not a bug - you're delusional. No, what you think is not at all how notices were designed. From the manual (ht

Re: [PHP-DEV] Deprecate PHP's short open tags, again

> Le 14 août 2019 à 19:01, Olumide Samson a écrit : > > This was exactly my reason for participating in this discussion, if such > simple BC break encounters fierce and lengthy-weighted resistance, I'm not > sure there will ever be a BC break, only additions without a necessary > cleanup. > >

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

> Le 6 août 2019 à 20:46, Nikita Popov a écrit : > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. wrote: > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >>

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

> Le 29 juil. 2019 à 16:40, Nikita Popov a écrit : > > > You seem to be agreeing with what I originally said: That by-reference > passing is mainly useful to interoperate with by-reference internal > functions, which don't exactly leave you with a choice. > To be clear: No, I’m not agreein

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

> Le 28 juil. 2019 à 21:12, Marco Pivetta a écrit : > > On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev > wrote: > >> Hi! >> >>> Nah, by-ref is pretty much avoided in OSS packages, but we can surely >>> survey the ecosystem to verify this. >> >> I literally work with code that uses refe

Re: [PHP-DEV] Stop replacing dots with underscores in query, post andcookie parameters for PHP 8?

> Le 24 juil. 2019 à 00:52, Stanislav Malyshev a écrit : > > Hi! > >> My preferred solution would be to add a new built-in function that >> re-does the mangling exactly as it used to be done. It would be no great >> maintenance burden on us to maintain such a function for the future, but >> it

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

> Le 23 juil. 2019 à 19:54, G. P. B. a écrit : > > The only point of contention of this RFC that I potentially see is the > removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > instead of it being removed in PHP 9 after it having had a whole major > version release cycle. R

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 8 juil. 2019 à 18:52, Andrey Andreev a écrit : > > Hi, > > On Mon, Jul 8, 2019 at 4:54 PM Claude Pache <mailto:claude.pa...@gmail.com>> wrote: >> >> >>> Le 8 juil. 2019 à 15:20, Christoph M. Becker a écrit : >>> >>>

Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.4

> Le 8 juil. 2019 à 21:27, Nikita Popov a écrit : > > Hi internals, > > I've opened voting on the deprecations for PHP 7.4 RFC: > https://wiki.php.net/rfc/deprecations_php_7_4 > > As usual, each deprecation has it's own vote and requires its own, > independent 2/3 majority to pass. Voting clos

Re: [PHP-DEV] [VOTE] Strict operators directive

> Le 9 juil. 2019 à 12:09, Andreas Heigl a écrit : > > > > Am 09.07.19 um 12:06 schrieb Christian Schneider: >> Am 09.07.2019 um 11:30 schrieb Marco Pivetta : >>> I wasn't sure about the full implications of this, but after some thought, >>> the worst that can happen is excessive strictness,

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 9 juil. 2019 à 09:40, Peter Bowyer a écrit : > > On Mon, 8 Jul 2019 at 19:09, Björn Larsson > wrote: > >> Having this _ci postfix is a new way of indicating case insensitivity. >> I think that it might add to negative votes. Personally I think it's a >> good idea to mimic existing ways

Re: [PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 8 juil. 2019 à 15:20, Christoph M. Becker a écrit : > > FTR, there is already substr_compare(). `substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the

Re: [PHP-DEV] [RFC] Deprecations for 7.4

The deprecation RFC lists `apache_request_headers()`, because it is “an Apache-specific name is also available in other SAPIs, even though it is also available under the SAPI-independent name getallheaders()”. Have you ever thought about making a more thorough and consistent change with other s

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

> Le 3 juil. 2019 à 17:59, Nikita Popov a écrit : > > On Wed, Jul 3, 2019 at 4:41 PM Levi Morrison wrote: > >> Was any analysis of usage done for top open source projects? I support >> this direction, but would prefer to know its current impact before >> voting. >> > > I checked top 2k pro

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 11:36, Benjamin Morel a écrit : > >> (...) could be the case depending on a declaration somewhere else in the > source code. >> That's the confusion Claude and I were talking about: You cannot be sure > what a very simple line of code does. > > Oh, I see. You mean that onl

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 08:50, Christian Schneider a écrit : > > Am 25.06.2019 um 15:09 schrieb Arnold Daniels : >> This RFC proposes a new directive 'strict_operators'. When enabled, >> operators may cast operands to the expected type, but must comply to; >> >> * Typecasting is not based on the

Re: [PHP-DEV] [RFC] Deprecations for 7.4

> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen a écrit : > > Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev > : >> My first question for many of those is - why? I.e. it deprecates a bunch >> of niche functions. Most people do not use these functions, so they >> probably don't

Re: [PHP-DEV] [RFC] Deprecations for 7.4

> Le 21 juin 2019 à 20:15, Bishop Bettini a écrit : > > On Fri, Jun 21, 2019, 13:54 Claude Pache <mailto:claude.pa...@gmail.com>> wrote: > > > > Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen > <mailto:ka...@php.net>> a écrit : > > > >

Re: [PHP-DEV] [RFC] Deprecations for 7.4

> Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen a écrit : > > Greetings Internals > > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in P

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

> Le 17 mai 2019 à 09:35, Peter Bowyer a écrit : > > This could be a good time to make all blocks on the page collapsible, with > a "Collapse/Expand all" link added at the top. > > All added as progressive enhancement, so people with JavaScript disabled > see everything. There is no need for

Re: [PHP-DEV] Error instead of returning false

> Le 7 mai 2019 à 16:22, Gert a écrit : > > Hello internals, > > I wanted to propose an RFC, but i'd like to check first if this idea > has been considered before already. > > My idea, extremely summarized, would be to take the functions that > return false/null when they 'error', and instead m

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

> Le 24 avr. 2019 à 11:10, Björn Larsson a écrit : > > Den 2019-04-22 kl. 10:09, skrev Nikita Popov: >> On Tue, Apr 9, 2019 at 11:54 AM Nikita Popov wrote: >> >>> Hi internals, >>> The only objection here came from Gabriel, and I don't think we'll come to >>> an agreement. >>> Inspired by Bo

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 9 avr. 2019 à 12:47, Nikita Popov a écrit : > > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote: > >> Nikita Popov wrote: >>> I'm always a fan of making things stricter, but think that in this >>> particular case there are some additional considerations we should keep >> in >>> mind.

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> Le 13 avr. 2019 à 11:09, Stijn Peeters a écrit : > > Is anyone aware of other arguments for not allowing normal arguments after > unpackable arguments in function calls? I've grabbed into the archives of internals. Apart from technical issues: The main argument against that affordance was

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

> Le 10 avr. 2019 à 21:21, Stanislav Malyshev a écrit : > > Hi! > >> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a >> deprecation and removal of the left-associative behavior of ternaries. >> Instead, explicit parentheses should be used: >> >> https://wiki.php.net

Re: [PHP-DEV] [RFC] Nullable Casting

> Le 8 avr. 2019 à 07:05, David Rodrigues a écrit : > > And about "settype($variable, "?int")" it was requested on original mailing > by Claude Pache. PHP has several ways to perform casting: 1. (int) $foo 2. settype($foo, 'int'); 3. intval($foo) Th

Re: [PHP-DEV] [RFC] Nullable Casting

> Le 8 avr. 2019 à 12:24, Stephen Reay a écrit : > > if your target ’type’ is `?int` and you pass an empty string, wouldn’t you > expect to get `null` rather than `0` ? You should get the same value than you get in: ```php declare(strict_types=0); function foo(?int $x) { return $x; }

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> Le 5 avr. 2019 à 09:45, Stijn Peeters a écrit : > > Hi, > > If I understand correctly it is possible in this proposal to use normal > arguments after using an unpackable argument: > > $arr4 = array(...$arr1, ...$arr2, 111); //valid > > This is something that is not possible when usi

Re: [PHP-DEV] Question about adding !function_identifier

> Le 3 avr. 2019 à 18:52, M. W. Moe a écrit : > > Hello, > > not documenting at first is not really a question of laziness or so, as > things are still moving around > you absolutely need this agility; a good design layout between theory and > stable state will refactored > discussed a thous

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

> Le 3 avr. 2019 à 11:51, Benjamin Morel a écrit : > > Hi internals, > > I just used PHP_FLOAT_MIN for the first time, and was surprised that it is > the smallest **positive** number representable. Is this expected? > > This is unlike PHP_INT_MIN, which is the absolute smallest representable

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 16:14, Benjamin Morel a écrit : > > > Sure, PHP has the huge advantage here to have a dedicated string > concatenation operator, removing any ambiguity around the + operator. This > does not mean that we cannot borrow their semantics for string/number > comparison! I wa

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 14:29, Benjamin Morel a écrit : > > Thinking about this a bit more, what about following JavaScript semantics? I > find them really good in this respect: > Arithmetic in JavaScript cannot be used reliably (in general) without converting your data to the proper type, beca

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 00:09, Benjamin Morel a écrit : > > - I would also strongly suggest that 2 strings are always compared > byte-by-byte; IMO it does (*somehow*) make sense that 42 == "42.0", but it > DOES NOT make sense that "42" == "42.0". (...) There are many ways to obtain numeric data

Re: [PHP-DEV] [RFC] DOM Living Standard API

Beware that behaviour of some methods should differ between HTML and non-HTML documents. For instance, the RFC says: > DOMElement→nodeName casing was previously undefined, it is now changed to > always uppercase. However, the DOM Living Standard says it is uppercase (even, ASCII-uppercased) on

Re: [PHP-DEV] [RFC] Saner string to number comparisons

> Le 27 févr. 2019 à 09:06, Kingsquare.nl - Robin Speekenbrink > a écrit : > > As of the 0 == "" bit: I do think that an empty string is widespread > regarded as falsey-string... Thus 0 == "" sould IMHO return true... > 0 == "" evaluating to true has been a footgun for me in the past; someth

Re: [PHP-DEV][RFC] Allow void return type variance

> Le 4 févr. 2019 à 04:22, Wes a écrit : > > Hello PHPeeps! > > Recent events convinced me to write this RFC :P > > Please have a read here https://wiki.php.net/rfc/allow-void-variance > > I am targeting all the supported PHP versions because this is mainly to > placate the discontent that a

Re: [PHP-DEV] Deprecation ideas for PHP 8

> > And then there is *array_multisort* a function which has a signature which > isn't even possible in userland code. > (https://secure.php.net/manual/en/function.array-multisort.php > ). > Other than the fact that this function's

Re: [PHP-DEV] [RFC] New custom object serialization mechanism

> Le 28 janv. 2019 à 08:58, Marco Pivetta a écrit : > >> >> Here, both aspects are not desired: we don't want ppl to type-hint for >> e.g. Serializable - and too bad it exists because I've already seen ppl >> think: "hey, I'll type-hint or extend it to express I want a serializable >> thing".

Re: [PHP-DEV] Deprecation ideas for PHP 8

> Le 23 janv. 2019 à 14:19, Girgias a écrit : > > > > On Wed, 23 Jan 2019 at 09:19, Claude Pache wrote: > >> >>> - settype >> >> AFAICS, there is no easy replacement for settype(). If the second argument >> is a string literal, you

Re: [PHP-DEV] Deprecation ideas for PHP 8

> - settype AFAICS, there is no easy replacement for settype(). If the second argument is a string literal, you can use type coercion + assignment at the price of duplicating the occurrence of the first argument. If the second argument is not known at compile time, you have to resort to a

Re: [PHP-DEV] Don't silence fatal errors

> Le 26 nov. 2018 à 22:42, Nikita Popov a écrit : > > Hi internals, > > When the silencing operator @ is used, the intention is generally to > silence expected warnings or notices. However, it currently also silences > fatal errors. As fatal errors also abort request execution, the result will

Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2

> > 3) Object properties may be type hinted and the class author has until the > end > of the constructor to make sure they're fulfilled, otherwise TypeError on the > spot (what I'm proposing). Just to be sure you don’t miss the herd that this elephant is concealing: In addition, you *must* f

[PHP-DEV] Assigning to a reference returned by a function/method

Hi internals, Today I tried something like that: and it failed miserably (Fatal Error: Can't use function return value in write context). Naturally, as workaround, I could write: which is passable for one instruction, but not so much for ten similar instructions in a row. Another hacki

Re: [PHP-DEV] Nullable cast (?int)

> Le 31 juil. 2018 à 21:07, Sara Golemon a écrit : > >> On Tue, Jul 31, 2018 at 2:23 PM, David Rodrigues >> wrote: >> Currently we have support to (int) cast (and similar). But I do think that >> we too need a possibility to do a nullable cast. In terms, it will cast to >> (int) only if valu

<    1   2   3