> 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 

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.


[^1]: https://externals.io/message/112209#112214

Reply via email to