[RFC] Scalar Type Hints v0.2

Hi Marcio,

We still have a BC break but now we also have code with mutant behavior that might become buggy (do unexpected things) if a declare is used. As a language user and a package maintainer it would be a huge problem. Imagine how would be to maintain a package that can be used with both strict and coercive type checking. We would have to write 2x more tests and yet pollute code with manual type checks (is_string, is_integer) for the non strict runtime mode when type check is necessary.

I don’t see why this would create “mutant” or “buggy” behaviour. You always get the type you ask for: the weak behaviour is precisely the same as in v0.1. The strict behaviour is fairly intuitive. In no case will you ever receive the wrong type.

I don’t understand.

Andrea Faulds
http://ajf.me/

-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Wednesday, January 14, 2015 11:33 AM
To: Leigh
Cc: PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

Hi Leigh,

I really don't like this behaviour being changed at the call site. If
I design a function that I know should only take a string, then I
want it to be an error if the user supplies anything else, so that
they know they messed up.

I don’t like the idea of being forced to use strict (or weak) type
checking
because the API author decided as much.

I don't either. But I don't like the user to do it either, it's something
that is a part of the language definition.

I completely agree with both Robert and Leigh. I liked the v0.1 one, but
v0.2 is DOA from my point of view. Arguably, from my POV, it's the one
option that's even worse than having strict typing exclusively.

Zeev

Hi,

Hi Leigh,

I really don't like this behaviour being changed at the call site. If
I design a function that I know should only take a string, then I
want it to be an error if the user supplies anything else, so that
they know they messed up.

I don’t like the idea of being forced to use strict (or weak) type checking because the API author decided as much.

What happens with that code:

$i = 1;
$a = myFunc( $i );

declare(strict_typehints=TRUE);

function myFunc( float $f )
{
return otherFunc( $f );
}

function otherFunc( float $f )
{
...
}

As author of strict code I need to replace

 return otherFunc( $f );

by

 return otherFunc( (float) $f );

I'm not sure

• if this is what a strict coder wants and

• if you find an acceptable way to test your strict code if it works
  with non-strict code.

Regards

Thomas

Hello,

Hi Julien,

Using declare() IMO, is a PITA.
Everything that can be done without the use of declare(), must be done without declare().

I would have prefered different syntax, like the ones we disccussed many years ago , having strict checks with the foo(string $a) syntax, and non-strict check with the foo((string) $a) syntax.

Actually, this approach came about mostly to avoid that. I don’t really like the idea of mixing and matching weak and strict type checks. Having some functions using (int) and (string), others use int and string, and others still use both, would be confusing. Plus, it would mean that you’d be forced to follow the personal preference of the API authors.

With this RFC, yes, you have to put an extra line at the top of the file. But it has the advantage that everything follows the same behaviour, even extension/built-in functions. That’s what I like about it.

I don't understand why it should be a bad thing that the API author
forces rules on the consumer. The opposite is IMO fundamental to the
concept of an API - the rules specified by the author are a contract
that the consumer agrees to, and which allows for the whole thing to
work properly.

In this form, I don't get any benefit from strict type checks, because
I only want them so that writing foo(int $bar) guarantees me that the
caller passed an integer. Instead, I'd have to NOT use a type hint,
and instead do an is_int($bar) check inside ... this beats the whole
purpose.

This caller-controlled switch very much reminds me of
mbstring.func_overload, which I didn't care much for, until one day I
saw how it breaks all crypto code that authors had otherwise written
very carefully.

I prefer Julien's (int) $weak vs. int $strong syntax better (which is
what I've always wanted), but I don't care much if it's a declare()
statement, just as long as the author controls the behavior.
And while I'm on that - thank you for this proposal (specifically the
0.2 version), Andrea. Finally an RFC that allows both weak and strict
scalar type checks instead of the "can't go in both directions"
nonsense that has blocked this feature for years.

Cheers,
Andrey.

Am 14.01.2015 um 23:39 schrieb Andrea Faulds:

Hi Marc,

1. Inconsistencies of ZPP and explicit casts

In my opinion it should be the same if you call a function in weak type mode and calling a function in strict type mode with explicit cast.

But that would require to remove inconsistencies of ZPP and explicit casts.
Explicit casts and implicit casts have different behaviour, and that is definitely a good thing. Implicit casts can and should fail if the conversion isn’t sensible. Explicit casts aren’t supposed to fail.
That's a big problem for the strict type mode because of you have to
explicit cast to pass function signature which would result in a much
unsafer behavior were you originally wont a strict behavior. The only
way to be safe would be to use extra function calls for casting.

2. Only one choice for the language

In my opinion scalar types should be hinted strict and the caller of an API have to be sure to pass the right types. The caller have to know about the function he calls and he already should know what the function expects. This is the point were the caller have to know the type of an expected argument and he should know his own types. So he is the one how can pass the variable or make an explicit type cast.
This is all very well and good, and strict typing has its advantages, but there are a lot of people who do not want to have to deal with a strictly-typed API.
It's only a personal feeling for scrict typing but it requires casting
to be fixed.
But I have to agree with that casting is part of the caller with or
without this choice.

The library author only defines the type he requires but the caller is
the one have have to do so. Week typing in this case only helps the
caller to automatically cast.

3. Reserved words

I don't like it adding so much reserved words.
This doesn’t add any reserved words. It prevents the usage of some names for class names.
Preventing usage of some names means the same as reserved names at least
in the contest of class names.

As I understand it correctly the reservation is because of naming collisions on type-hints with scalars and classes/interfaces.

Why not adding these types as classes (marked final and not allowed to be initialized for now)?
Because then you’d have to do this at the top of every single file:

use php\typehint\int;
use php\typehint\float;
use php\typehint\string;
use php\typehint\bool;

Considering how much people seem to dislike the idea of using declare() for strict typing, I can see how poorly that would go down.
Such types should be on the root namespace. So the only difference would
be a backslash and only if you are within a namespace.

And to reaped myself you can do vary useful:

// internal pseudo code
class Scalar {}
interface Numeric {}
class Integer extends Scalar implements Numeric {}
class Float extends Scalar implements Numeric {}
class String extends Scalar {}
class Array implements Traversable {}

// users code
function increment(numeric $num) { return $num + 1; }
function incrementInt(integer $int) { return $int + 1; }
function incrementFloat(float $float) { return $float + 1; }

// in namespace
function increment(\numeric $num) { return $num + 1; }
function incrementInt(\integer $int) { return $int + 1; }
function incrementFloat(\float $float) { return $float + 1; }

More importantly, this would be inconsistent with our existing type hints like array and callable.
It would only be inconsistent if you don't think it through end but sure
it's more work. I have no idea how much.

On calling a function in week mode one or more magic methods could be
used to add auto cast behavior like:

public function __toInt();
public function __toFloat();
public function __toString(); // it will be called already
public function __toArray(); // Not part of this RFC
public function __toInstanceOf($name); // Will be called if no one of
the other pass

4. Only one naming

I dislike the proposed aliases. The type names should be defined once without aliases and the manual and error massages should be changed to be consistent.
In an ideal world we would only have the short or long form, sure. But this isn’t an ideal world, and PHP doesn’t have compile-time validation of type hints. It would be too easy to write foo(integer $bar) and miss that it is broken if the function isn’t called.
Please let us make PHP more ideal ;)

Your argument is nonsense. As long as you never test your (unittest or
manual) you can't be sure to work well. The same argument could pass for
current type-hinting. If that argument is serious you have to eg.
automatically fix type errors in class names.

Btw. IDEs already warn if you use something undeclared project wide.

I don’t think having both int and integer is really a problem. It’s not going to cause confusion, they are obviously the same type. Coding style guides will mandate one or the other.
What about double and real?

Thanks.

Andrea Faulds
http://ajf.me/

Thanks

Marc

Hey:

Hey Dmitry,

In my opinion, version 0.1 was consistent enough.

handling two different approaches just makes mess...

We have internal function strlen(string $s), and it may be called with integer argument e.g. strlen(123) -> 3
I think user functions should follow the same rules.

This RFC does that. In the “weak” mode that would continue work, and it would also for userland functions with scalar type hints. In the “strict” mode that would break, and it would also break for a similar userland function with a scalar type hint.
sounds like a hell to me.....

sorry for saying that, but I don't like the whole "declare" thing...

could we please strict to v0.1, only make it first ?

thanks

If some rules are "bad", lets change that rules for both internal and user functions.
But it's better to do it in a separate RFC (after scalar type hinting 0.1 accepted), or we will stick forever.

I’m not sure the weak typing approach to function parameters is bad per se, but a lot of developers would certainly prefer the strict typing approach. That’s why the RFC allows choice: for all the people that weak typing works for, good, you can keep using that. The people who want strict typing get strict typing without forcing the people who want weak typing to use it.

Thanks.

Andrea Faulds
http://ajf.me/

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggiano@seld.be
wrote:

Reading the thread at this point shows so much confusion, it seems half
the
people reading the spec misunderstood that the declare() line affects
function calls only and not the API/implementation level.

As much I think it was a smart idea and workaround, it is perhaps too
clever
for its own good if nobody gets it.

Anyway, as v0.2 appears to be v0.1 + declare(), why not keep those two
options separated in the vote?

a) should be add weak typing
b) should we also add declare() for to get strict typing at call-site.

If a passes it would be a great stepping stone towards adding b later
perhaps, or tweaking internal coercion rules to improve the behavior of
the
weak types, having scalars in return hints (since return hints seem
likely
to pass), etc.

If b passes as well great we have a complete picture and every team can
have declare() Y/N in their own coding guidelines based on preference.

Yeah, while the confusion is definitely still there, I would
personally argue that definitely some people who oppose the declare()
get that it's only for calls in the file - and still don't find it
clever.

The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to have declare() in both
files.

This alone is a very big argument against it imho. Next argument
would be using different libraries in one file and wanting one of them
to be strict the other not.

I get the idea following something like "use strict;" approaches of
Perl/Javascript,
however AFAIK they only affect the file itself, not calls from the file to
another one.

Pavel Kouril

The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to have declare() in both
files.

Agreed there are gotchas but not only with declare().

Many things can go wrong when you move a function somewhere else, for
example you might leave use statements behind and suddenly a catch (FooException $e) will fail to match exceptions or something sneaky
like that. I don't necessarily think that's enough to kill the feature.

Note that you can only get problems going from weak to strict context by
the way, the other way around should not cause any issues, code would
just work when it otherwise would have triggered strict errors. Since
you usually move code into places you own, I'd assume you know it if you
are using strict typing.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

Hi Pavel,

Reading the thread at this point shows so much confusion, it seems half the
people reading the spec misunderstood that the declare() line affects
function calls only and not the API/implementation level.

Yeah, while the confusion is definitely still there, I would
personally argue that definitely some people who oppose the declare()
get that it's only for calls in the file - and still don't find it
clever.

The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to have declare() in both
files.

This is true, you would sometimes have problems if you’re mixing the strict and weak type checking modes in your codebase.

The intention is that you’d use one or the other exclusively, perhaps with some minor exceptions as and where necessary. The fact it’s weak by default means you could add scalar type hints gradually without breaking things, because the weak mode is quite permissive. Then, if you wanted to, you could gradually migrate each file in your codebase over to strict mode.

Essentially, you get “gradual typing” like Hack, but without Hack’s approach which I don’t particularly like. Hack’s approach is to simply not enforce type hints if they’re a problem. On the other hand, this RFC would alway enforces them, but the weak mode is less strict.

So, I anticipate that while it would cause problems during a transition, I think codebases would end up using one mode or the other exclusively and wouldn’t have problems once they had done so.

Thanks.

Andrea Faulds
http://ajf.me/

Hi Dmitry,

--
Andrea Faulds
http://ajf.me/

As I already told, in my opinion, version 0.1 was the perfect solution that fit into PHP semantic very well.

declare(strict_types=1); - is really weird solution.
It changes type hinting behavior per file scope, so, just to try strict type hinting in a big project, people will have to change every single PHP file.
From the RFC text, I didn't completely understand, if declare() affects call site or declaration. Will we able to call the same function using weak type hinting from on file and with strict from the other?
"The strict type checking mode also affects extension and built-in PHP functions", sin(1) - error !!!

Strict type hinting is not suitable for PHP by definition (as a weakly typed language), however, I see, it may be useful in some cases.
I would prefer to have "weak" types at first, then think about introducing ability to switch to "strict" type hinting in context of use-cases.

Thanks. Dmitry.

Good evening,

The RFC has been updated to cover return types, since Levi’s Return Types RFC has passed. The patch is a work in progress: it works, but lacks tests for return types.

Version 0.3 of the RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints

Thanks!

Andrea Faulds
http://ajf.me/

Hi Dmitry,

As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.

I don't like the original. Weak types work to a degree, but they don't fulfill the use case of a lot of developers, and consequently the RFC wasn't too popular outside internals.

declare(strict_types=1); - is really weird solution.

It is unusual, that is true. But it has some benefits.

It changes type hinting behavior per file scope, so, just to try strict
type hinting in a big project, people will have to change every single PHP
file.
From the RFC text, I didn't completely understand, if declare() affects
call site or declaration.

Ah, my bad. It affects function calls and return statements within the declare block, or remainder of the file if there's no declare block. So parameter types are checked using the mode chosen by the calling code, while return types are checked using the mode chosen by the called code.

Will we able to call the same function using weak
type hinting from on file and with strict from the other?

Yes, for the parameter type hints anyway. That means that strict and weak code is interoperable without enforcing a model on each other.

"The strict type checking mode also affects extension and built-in PHP
functions", sin(1) - error !!!

That particular case is probably unpopular - although strict type hinting for ints and floats can prevent nastier errors later (float out of int range, or silent loss of precision from int to float).

Strict type hinting is not suitable for PHP by definition (as a weakly
typed language), however, I see, it may be useful in some cases.
I would prefer to have "weak" types at first, then think about introducing
ability to switch to "strict" type hinting in context of use-cases.

That'd be possible, but I fear that we'd just end up with weak typing only and no strict solution. Regardless of its merits, a large portion of the community is in favour of a strictly-typed solution. There are also a lot of people who are in favour of weak typing. So, this RFC tries to make a compromise.

Thanks.

--
Andrea Faulds
http://ajf.me/

As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.

declare(strict_types=1); - is really weird solution.
It changes type hinting behavior per file scope, so, just to try strict
type hinting in a big project, people will have to change every single PHP
file.

THis is why I believe it makes more sense to have this switch on the
callee side, instead of on the calling side.

cheers,
Derick

Good evening,

The RFC has been updated to cover return types, since Levi’s Return Types RFC has passed. The patch is a work in progress: it works, but lacks tests for return types.

Version 0.3 of the RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints

I think v0.1 had pretty good chances to get accepted, but I’m not so sure about anything that followed.
I’m definitely -1 on declare(strict).

I agree. I understand that someone might prefer strict typing, but
declare() seems so different from anything else in php. I think I've
only used it when I needed signal handling and even in that case it felt
so weird.

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

what about giving several voting options? yes/no for scalar type hints and yes/no for declare-strict

Regards
Thomas

Michael Wallner schrieb am 2. Feb 2015 09:49:

Good evening,

The RFC has been updated to cover return types, since Levi’s Return
Types RFC has passed. The patch is a work in progress: it works, but
lacks tests for return types.

Version 0.3 of the RFC can be found here:
https://wiki.php.net/rfc/scalar_type_hints

I think v0.1 had pretty good chances to get accepted, but I’m not so
sure about anything that followed.
I’m definitely -1 on declare(strict).

Regards,
Mike

Hi Markus,

• Since consensus on the strict mode does part the community (or, the
  greater community also outside @internals) my impression is that the
  current best way to move forward would be

• get the rfc to only go for weak types for now

• using the "cast-like syntax": function foo( (int) $bar );

and ultimately keep the strict type out for /now/ and try it at a later
time, the "function foo( int $bar )"-syntax.

I’m not sure that really works that well. It’s not a terribly good compromise: If you want strict typing, you not only haven’t got it, but even worse, you’ll be forced to deal with weak typing if you use the wrong library, because the (int) syntax would be specifically for weak types. It’s not really a compromise at all, actually.

I'm actually not really in favor of just weak types, I would consider
myself a "strict type" voter, but through the community communication
here I saw a) the benefits of weak types hinting/casting b) without
getting in the way of a possible future strict type (e.g. with the
"non-cast-like syntax”).

Well this RFC tries to strike a different balance: rather than having the chaos of some functions using weak types, others strict types, others both, it just adds scalar types and lets you choose the behaviour that suits you. It means weak typing fans can live in their weakly-typed world, and strict typing fans can live in their strictly-typed world. That’s the idea, anyway.

But I’m just going in circles at this point. :P

Thanks for your contributions.

--
Andrea Faulds
http://ajf.me/

Hi Matthew,

Good evening,

The RFC has been updated to cover return types, since Levi’s Return Types RFC has passed. The patch is a work in progress: it works, but lacks tests for return types.

Version 0.3 of the RFC can be found here: https://wiki.php.net/rfc/scalar_type_hints

After thinking and talking this over, I do think your RFC is the only
option that makes sense if you want to support both weak and strict.
However, I think the usage of declare() makes it dead in the water.
Fair or not, I have a hard time looking past that.

Ah, that’s unfortunate. I know declare() is ugly and a little unwieldy, but I can’t see another way to do it which doesn’t cause bigger problems. I am convinced that if this RFC passed, people would probably get used to declare(). IDEs and command-line tools do exist.

I'm opposed to other compromises because I think it will be a big mess
from the caller's perspective. (Some functions would be strict, some
would not ... eventually forcing everybody to just use strict types.)
And, as I've stated previously, I prefer strict types.

That’s how I feel as well.

Does the implementation of strict-only work for testing right now? (If
so, what branch is it on, etc?) It's easy for everybody to theorize
about how this would work, but why not actually take the time to
"strictify" some part of a commonly used library and see how it
actually works in practice? But a library with type-hints + a script
to prepend "use strict" to every PHP file would make testing impact on
real-world usage easy for anybody.

The implementation does work for testing. I still need to write tests for return types but they seem to work. Parameter types are fully-working, though, and they have extensive tests, so I know they’re working fine and you could add them to an existing project.

Strictifying an existing library is a good idea. I’ll try “strictifying” one of my bigger personal projects (PictoSwap, a 3DS browser application with a PHP backend) and see how it goes. I expect it’ll be fairly smooth, we’ll see.

Thanks for your thoughts.

Andrea Faulds
http://ajf.me/