> Am 3.6.2016 um 18:49 schrieb Larry Garfield :
>
> On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
>> On 03/06/2016 15:58, Thomas Bley wrote:
>>> To me type declarations help to make my code easier and more consistent.
>>> Having multiple scalar types for a single function parameter is against
>>
On 6/3/2016 5:13 PM, Andrea Faulds wrote:
> The RFC uses simple rules, but the resulting behaviour is complex.
>
> PHP's weak typing rules are complicated enough as they are, and cause
> enough problem, without the addition of yet more rules, this time for
> how weak typing should work within unio
On 6/3/2016 3:40 PM, Theodore Brown wrote:
> I am also in favor of the proposal to replace ?QuestionMarkNullables
> with union|null. Having a single way to declare nullable types will
> keep the reflection API simpler, make things easier for static
> analysis tools, and prevent developers from havi
Hi!
> Would it be COMPLETELY antisocial at this point to ask for a secondary
> vote on this RFC for adding the "num" type which is an alias for (int
> | float) ?
I think piling up votes that are not necessary for the specific RFC's
topic is not right. We can always have another RFC :)
--
Stas M
On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
On 03/06/2016 15:58, Thomas Bley wrote:
To me type declarations help to make my code easier and more consistent.
Having multiple scalar types for a single function parameter is
against this goal since I need extra logic to handle this.
e.g. functi
Of course combining string + false + null makes sense, we use that every day
with core functions and libraries,
but combining string with bool (true and false), int, float, etc makes no sense
to me.
let's look at an example from some older mdb2 code:
/**
* Tell whether a value is a MDB2 error.
On 03/06/2016 15:58, Thomas Bley wrote:
To me type declarations help to make my code easier and more consistent.
Having multiple scalar types for a single function parameter is against this
goal since I need extra logic to handle this.
e.g. function foo(string | int | bool $bar) {} makes no sen
Hi,
Bob Weinand wrote:
I think this is more of a presentation problem.
As you say, there's not much a better way to do that.
Well, that's why I question if we should do it at all, if there's no way
to do it without this complexity.
It's basically our weak casting rules, just applied to the
To me type declarations help to make my code easier and more consistent.
Having multiple scalar types for a single function parameter is against this
goal since I need extra logic to handle this.
e.g. function foo(string | int | bool $bar) {} makes no sense in weak mode
since string can already
On 03/06/2016 15:24, Thomas Bley wrote:
maybe easier to get a majority from voters if defining union types only in
strict mode for 7.1?
No go, I'm afraid.
Strict types are opt-in at the point of calling the function, but union
types are a feature of the declaration. If I write "function foo(
maybe easier to get a majority from voters if defining union types only in
strict mode for 7.1?
Regards
Thomas
Rowan Collins wrote on 03.06.2016 15:40:
> On 03/06/2016 13:30, Bob Weinand wrote:
>>
>> The *weak casting* rules (i.e. what gets converted how and what can be
>> converted to the othe
Results for project PHP master, build date 2016-06-03 06:28:02+03:00
commit: b7bb6d0
previous commit:1b4946e
revision date: 2016-06-03 00:19:23+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 3 June 2016 at 11:19, Björn Larsson wrote:
> One could add that not all development / debugging is done through
> an advanced IDE. Logging in to production server with SSH ending up
> with a terminal window, only having Emacs or Vi at your disposal is
> still valid today.
>
s/valid/inconsider
On 03/06/2016 13:30, Bob Weinand wrote:
The *weak casting* rules (i.e. what gets converted how and what can be
converted to the other type) are not an invention of the proposal.
The proposal however defines the specific order.
I’ve added a reasoning why not left-to-right now. As this seemed to
On Thu, 2 June 2016 Bob Weinand wrote:
> Hey all,
>
> I know, it has been quite some time … but it's still well in time for 7.1.
>
> Time to move on and put Union types to vote soon. [In the next 1-2 days]
>
> We have done some changes to the RFC to emphasize the appeal of
> union types as well
> Am 3.6.2016 um 14:18 schrieb Rowan Collins :
>
> On 03/06/2016 12:59, Bob Weinand wrote:
>>> function l(string | float $x) { echo gettype($x); }
>>> l("1.5a"); // I would expect string, but float would succeed if attempted
>>
>> Exact matches *ALWAYS* match without coercion.
>
> Gah, I keep m
On 03/06/2016 12:59, Bob Weinand wrote:
function l(string | float $x) { echo gettype($x); }
l("1.5a"); // I would expect string, but float would succeed if attempted
Exact matches *ALWAYS* match without coercion.
Gah, I keep making that mistake in my examples. I did say I was
struggling to g
> Am 3.6.2016 um 12:28 schrieb Rowan Collins :
>
> On 03/06/2016 11:16, Thomas Bley wrote:
>> why not try all types weakly from left to right in weak mode?
>> Rule: if type check would give a fatal error for a type, try next type.
>
> This is what I suggested, but Bob is insistent that weak mode
On 03/06/2016 11:16, Thomas Bley wrote:
why not try all types weakly from left to right in weak mode?
Rule: if type check would give a fatal error for a type, try next type.
This is what I suggested, but Bob is insistent that weak mode should
always select the same type as strict mode where th
why not try all types weakly from left to right in weak mode?
Rule: if type check would give a fatal error for a type, try next type.
E.g.
function i(int | string $var) { echo gettype($var) . ' ' . $var; }
i('10'); // int 10
i('10a'); // int 10
i('foo'); // string foo
i(10.0); // int 10
i(10); //
Hi,
Years ago I reported what I thought should be fairly simple to resolve.
The issue number (below) is that now the zend code goes through the
following logic
# test 1
#define __restrict__ restrict
later test #2
# define __restrict__
And always:
#define restrict __restrict__
In this case:
Den 2016-06-02 kl. 18:59, skrev Fleshgrinder:
On 6/1/2016 9:46 PM, Ronald Chmara wrote:
Hi.
https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c1749162260592
was my commit, put together as a result of discussions on this list
(and sidebars). I can try to speak to it from memory.
22 matches
Mail list logo
