> On Apr 16, 2022, at 23:48, Mike Schinkel <m...@newclarity.net> wrote:
>
> Hi PHPers,
>
> As I have been following the discussion about the need for a "true" type to
> allow documenting that a function should only be able to return true vs. bool
> which would allow false, and in the past the same argument for false vs.
> true, it occurs to me that there is another approach to address this rather
> than add values to be types which AFAIK has not been mentioned on the list
> before.
>
> An alternate solution to possibly consider might be to add the concept of
> "constraints" to PHP that could work alongside types. This occured to me
> because I am mostly doing Go programming now and constraints is effectively
> how Go handled an equivalent conundrum for the Generics they just added.
>
> Consider if PHP allowed the following and if PHP would allow type hints to
> use *either* a type *or* a constraint where the values on the right hand side
> are expressions (I was just spitballing the syntax; other syntaxes or even
> concept names might represent this concept better):
>
> constraint true: true
>
> constraint false: false
>
> If we had constraints in PHP we could also have things like this:
>
> constraint Truthy: !empty($this)
>
> constraint Falsey: empty($this)
>
> constraint Percent: is_numeric($this) && 0 <= $this && $this <=100
>
> constraint DateTimeable: is_object($this)
> && (get_class=($this) == DateTime::class || get_class=($this) ==
> DateTimeImmutable::class)
>
> constraint ProductID: is_string($this) && strlen($this)==10
> && preg_match("#[A-Z]{2}[0-9]{8}#",$this)
>
> With the above, we could write functions like this and know they are more
> "type safe" than otherwise:
>
> function product_exists(ProductID $product_id):bool {...}
>
> Constraints could also be limited to using only standard library functions so
> that it would be possible to do static analysis on a constraint. Clearly a
> static analyzer could evaluate the constraints I represented above. And I
> *think* this could be backward compatible with false as a type, and even true
> with a type.
>
> FWIW I am just offering up an approach that seems to have worked well in Go
> for consideration. If you like it, please discuss it. If not, it was worth a
> try.
>
> -Mike
>
> P.S. I am sure there are many ways to improve what I proposed. Note this is
> *just* a straw man proposal; please offer suggestions for improvement.
>
This reminds me of some of the discussion we’ve had on list of type
aliasing.[^1]
I really like this idea and think it could be combined with type aliasing to
create powerful userland-defined types.
While you mention restricting to standard-library functions for easier
type-safety, I’m not sure it has to have that limitation. What we’re
effectively defining here is a kind of short-hand Closure that is then called
with the passed value at runtime to validate the type. A type alias could work
similarly, perhaps even with the same syntax.
Cheers,
Ben
[^1]: https://externals.io/message/112209#112214
