On Fri, Oct 27, 2017 at 10:51 PM, Fleshgrinder wrote:
> Hey Internals!
>
> We currently have a couple of things that are broken about constants,
> and I wanted to gauge if people are interested in a) fixing it as well
> as b) to get to know the root causes of these things.
>
> # 1
>
> A constant
Yes, abstracting such additional checks through something like
zend_hash_duplicate() would make sense, but IMHO it should be named
differently, e.g. zend_hash_copy_lazy. So to be analogous to
zend_string_copy(), but not to be confused with the existing zend_hash_copy().
By the way: array_pad()
Hey Internals!
We currently have a couple of things that are broken about constants,
and I wanted to gauge if people are interested in a) fixing it as well
as b) to get to know the root causes of these things.
# 1
A constant defined in an interface cannot be overwritten in the class
that impleme
Hi,
> If developers accidentally add/subtract leading space from the closing token
> then the whole string changes;
Yes, this is a feature of the chosen semantics. The indentation level of the
body can be chosen based upon the current indentation level of the code (for
which, the closing mar
On Fri, Oct 27, 2017 at 12:10 PM, Nikita Popov wrote:
> On Fri, Oct 27, 2017 at 4:16 PM, Sara Golemon wrote:
>>
>> On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu
>> wrote:
>> > Now, array_slice() could be optimized similarly, but currently
>> > (unless the resulting array is expected to be empt
On Fri, Oct 27, 2017 at 4:16 PM, Sara Golemon wrote:
> On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu
> wrote:
> > Now, array_slice() could be optimized similarly, but currently
> > (unless the resulting array is expected to be empty) we always
> > create a new array no matter if we actually ha
On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu wrote:
> Now, array_slice() could be optimized similarly, but currently
> (unless the resulting array is expected to be empty) we always
> create a new array no matter if we actually have to.
>
Pushed, with an additional escape hatch for vector-like
Hello Benjamin,
Am 27.10.2017 um 14:12 schrieb Benjamin Coutu:
> Hello everyone,
>
> Please consider these two statements:
>
> substr($string, 0, $length);
> array_slice($array, 0, $length, true);
>
> Currently, with substr(), if $offset is zero and $length is smaller or equal
> to the origina
On Fri, Oct 27, 2017 at 7:17 AM, Peter Cowburn wrote:
> On 24 October 2017 at 17:14, Sara Golemon wrote:
>> I'd guess because those are the only constructs which appear
>> function-like *and* exhibit variadic behavior.
>>
>> empty/die/exit/print/require/include/require_once/include_once/__HALT_CO
On 25 October 2017 22:52:37 BST, Dan Ackroyd wrote:
>Although 'array of' as well as full blown generics are popular ideas,
>I'm pretty certain the RFC failed due to the type check on the array
>happening every time the 'array of' was passed from one function to
>another, which would make it too sl
Hello everyone,
Please consider these two statements:
substr($string, 0, $length);
array_slice($array, 0, $length, true);
Currently, with substr(), if $offset is zero and $length is smaller or equal to
the original string length we just increase the reference count of the original
string and r
I am sorry for partial topic duplication regarding array-access.
Still, at least with `declare(strict_types=1);` auto-castings of
non-numbers should raise an error:
var_dump(false + 2);
var_dump(null + 2);
Exactly like `"" + 2`.
WDYT? Filippo
Il 27/10/2017 13:47, Christoph M. Becker ha scri
On 27.10.2017 at 11:49, Filippo Tessarotto wrote:
> Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
> "initialized" to null is casted to other types:
>
> $foo = null;
> var_dump($foo['bar']);
> var_dump($foo . 'bar');
> var_dump($foo + 2);
> var_dump($foo & 2);
> // At the
Am 27.10.2017 um 12:54 schrieb Niklas Keller:
pleae don't break code like this which is a useful case for access
directly a array field returned from a function and so makes this to
a one-liner without check the result
public function GetMaxSort(): int
{
return (int)my
On 24 October 2017 at 17:14, Sara Golemon wrote:
> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn
> wrote:
> > I know it's late in the game, but I have a quick question. This RFC
> > includes a couple of "Not really a function" functions (namely isset()
> and
> > unset()) that will also be able
>
> Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
>> "initialized" to null is casted to other types:
>>
>> $foo = null;
>> var_dump($foo['bar']);
>> var_dump($foo . 'bar');
>> var_dump($foo + 2);
>> var_dump($foo & 2);
>> // At the time being, this code produces no errors
Am 27.10.2017 um 11:49 schrieb Filippo Tessarotto:
Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
"initialized" to null is casted to other types:
$foo = null;
var_dump($foo['bar']);
var_dump($foo . 'bar');
var_dump($foo + 2);
var_dump($foo & 2);
// At the time being,
Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
"initialized" to null is casted to other types:
$foo = null;
var_dump($foo['bar']);
var_dump($foo . 'bar');
var_dump($foo + 2);
var_dump($foo & 2);
// At the time being, this code produces no errors
The eventual vote may be
18 matches
Mail list logo