If I had "scalar", "number" and ?T as types, the types I would need would be:
1. ?scalar|Decimal 2. ?scalar|Decimal|Expr 3. ?scalar|array 4. int|string (I *want* int|string here. I know array keys are always int|string. A wider type is lies.) 5. ?scalar (probably) 6. number 7. T|false 8. ?T 5 out of 8 still need a union. On Wed, Apr 20, 2016 at 9:01 PM, Zeev Suraski <z...@zend.com> wrote: > > > > -----Original Message----- > > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On > > Behalf Of Jesse Schalken > > Sent: Wednesday, April 20, 2016 1:12 PM > > To: Johannes Schlüter <johan...@schlueters.de> > > Cc: Andrea Faulds <a...@ajf.me>; PHP internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Re: Improving PHP's type system > > > > 1. I have a function that converts values to SQL which have SQL > > equivalents, including decimal values represented by a special Decimal > > class. It accepts int|string|bool|null|float|Decimal. > > 2. I have a class Expr which represents an expression in SQL. > > Expressions can be composed of other expressions, and of literal > values, so > > the constructors for Exprs accept > int|string|bool|null|float|Decimal|Expr. > > 3. I have a function that converts values to JSON that can be reliably > > converted back into their original. It accepts > int|string|bool|null|float. > > In other words, they accepts scalars (or nullable scalars). Introducing a > scalar type would do the job. > > > 4. I have a function that returns the first key in an array (or throws > > an exception if empty). It returns int|string. > > I'd argue that here too, a scalar would be fine. Worrying about a > floating point here is not a very relevant worry. > > > 5. I have a function that returns a value for a key in an array, and > > removes the key. The type of the key is things that are valid array > keys > > (int|string|bool|null IIRC). > > Scalar (or nullable scalar). > > > 6. I have a set of functions which operates on numbers. They accept > > int|float. > > Numeric (to also include strings that look like numbers when strict is not > on). > > > 7. All the PHP functions which say "returns ... or FALSE on failure" > > have their correct return type as T|false (where T is the return > value on > > success) (or T|bool is "false" is not an allowed type). > > How many of those do we have? As opposed to T|null? I think most > functions that return objects return null on failure, not false. And those > who don't can probably evolve to that approach. > > > 8. Nullability is nothing but a special case of union type with > T|null. > > Academically that's true, but practically speaking, the general T1|T2 is > almost always bogus while T|null subset makes a lot of sense. > > In reality, we can solve all the relevant use cases for union types by > relatively minor tweaks (or rather additions) to our scalar type hints, by > adding nullability, and by using interfaces where they make sense. > > Zeev >
