Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93749
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <c2609544-31cb-d699-4352-6e5497ee1d9b@gmail.com>
References: <BLU437-SMTP785CB095BE08FBC1CC2FAFE2580@phx.gbl> <0A.C5.62101.1C860575@pb1.pair.com> <a58caf44-dae1-c544-804f-089360243607@gmail.com> <BLU436-SMTP187447B1819635CD2E6962E2580@phx.gbl> <68b821ac-d71f-4be5-8dca-ae94db332630@gmail.com> <BLU436-SMTP208CF2757B67BA061C8EEADE2580@phx.gbl> <20160603101659.D466A1A81FC5@dd1730.kasserver.com> <6d448fd8-8fda-d795-accb-6b96cd128ccd@gmail.com> <BLU436-SMTP1304B21C2B677B1455A9E54E2590@phx.gbl> <652fdc5a-a164-2054-ed61-305a2b72330a@gmail.com> <BLU436-SMTP97AAE59E20D9AF3436B732E2590@phx.gbl><c2609544-31cb-d699-4352-6e5497ee1d9b@gmail.com>
To: internals@lists.php.net, rowan.collins@gmail.com
Message-ID: <20160603142421.346B81A81725@dd1730.kasserver.com>
Date: Fri,  3 Jun 2016 16:24:21 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types
From: mails@thomasbley.de ("Thomas Bley")

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 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 be
>> asked multiple times.
>>
>> Also, the specific reasoning why I propose that specific order the rules
>> are in:
>>> Otherwise PHP's casting rules are applied in an order to be as
>> lossless as possible.
>>
>> That’s really the only motivation behind that.
> 
> 
> Cheers, that's more or less what I thought.
> 
> I've yet to come up with a scheme that can be summarised any more simply 
> than that table, but FWIW below is how I've been trying to think about it...
> 
> 
> 
> 
> Strict mode rules are easy; try, in order:
> 0. Match without casting
> 1. Cast int -> float
> 
> Weak mode rules must start with the same rules strict mode would, to 
> avoid confusion.
> 
> After that, there are various casts available, and there's not a clear 
> precedent for the order that I can think of.
> 
> There are two somewhat contradictory aims:
> - use "narrower" types where possible, e.g. for string("") passed to 
> "int | bool" we probably prefer bool(false) over int(0)
> - use lossless casts where possible, e.g. for float(1.5) passed to "int 
> | string" we probably prefer string("1.5") over int(1)
> 
> The following casts are always lossless:
> 
> - anything -> string (with possible exception of float precision limits)
> - boolean -> anything (1 bit of information is easy to retain :P)
> 
> The following may be lossless in some common cases:
> 
> - string -> int (ctype_digit)
> - string -> float (roughly, is_numeric)
> - float -> int (whole numbers)
> - int -> float (where magnitude < 2^53, but this is pre-empted as high 
> priority by the strict rules)
> 
> The following are pretty much always lossy:
> 
> - anything -> boolean
> 
> 
> 
> 
> I'm not quite sure what to conclude from all that, but thought I'd write 
> it down for the record.
> 
> Cheers,
> -- 
> Rowan Collins
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>