What do we need strict scalar type hints for?

Hi Stas,

Hi!

Keeping that in mind, the declare statement, as ugly as it may look,
could be actually a killer to finally get what both camps want but
never (and never will) manage to agree.

I think having two conceptual frameworks in one language and having to
deal with (and potentially maintain) code bases with mixed conceptual
framework is a very bad idea. That would lead to a language
fragmentation as strict code will become hard to combine with non-strict
code within one application, and pretty soon people will start asking
questions like "is this library written in strict-PHP or non-strict-PHP?
ow, dang, we can't use it because we use the other one…"

I don’t see how. This proposal has been specifically designed to allow strict and non-strict code to be completely interoperable.

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

Hi!

Keeping that in mind, the declare statement, as ugly as it may look,
could be actually a killer to finally get what both camps want but
never (and never will) manage to agree.

I think having two conceptual frameworks in one language and having to
deal with (and potentially maintain) code bases with mixed conceptual
framework is a very bad idea. That would lead to a language
fragmentation as strict code will become hard to combine with non-strict
code within one application, and pretty soon people will start asking
questions like "is this library written in strict-PHP or non-strict-PHP?
ow, dang, we can't use it because we use the other one..."

Stas, I respectfully think you misunderstand the RFC.

I think one good way to make a parallel is to compare it to having
error_reporting(0); or error_reporting(E_ALL); on top of every file.

The RFC as it stands would make type hints be silently coerced by
default, so it would have "error reporting" disabled by default, but if
you set the declare line you do the equivalent of enabling error
reporting but only for your calls and returns.

Right now if you use a sloppy library for example that throws E_STRICT,
and you have reporting enabled, you do have fragmentation and it sucks,
for example:

// strict.php
include 'non-strict.php';
error_reporting(E_ALL);
foo();

// non-strict.php
error_reporting(0);
function foo() {
echo UNDEFINED_CONSTANT_FTW;
}
foo();

This produces:

UNDEFINED_CONSTANT_FTW
Notice: Use of undefined constant UNDEFINED_CONSTANT_FTW - assumed
'UNDEFINED_CONSTANT_FTW' in non-strict.php on line 5
UNDEFINED_CONSTANT_FTW

In this case the strict file by using a non-strict function gets
warnings thrown, so the community has to encourage/force everyone to
behave strictly in libraries otherwise their code does not integrate well.

On the other hand, with the type hints, every file chooses how they want
to behave and since it is not an ini setting it can not be influenced by
another file like in my example above. Consider this for example:

// strict.php
declare(strict_types=1);
include 'non-strict.php';
foo(10);

// non-strict.php
include 'strict2.php';
function foo(string $output) {
echo $output.PHP_EOL;
}
foo(5);
strictFoo(5);

// strict2.php
declare(strict_types=1);
function strictFoo(string $output) {
echo $output.PHP_EOL;
}

This results in:

5 // output of foo from non-strict context
5 // output of strictFoo from non-strict context
Catchable fatal error: foo() expects parameter 1 to be string, integer
given // failure of foo from strict context

So we see that the non-strict code works just fine on it's own, 5 gets
coerced to string, no matter if it's calling strict libraries or
non-strict ones, since it is itself non-strict. The strictness of others
does not influence non-strict code and everyone integrates very well
together.

When strict code calls non-strict code, they get errors if they pass
invalid params, but that is what they want since they asked to be
strict, so they get full on error reporting/static analysis of their
code, but do not push it on the whole ecosystem.

Cheers

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

-----Ursprüngliche Nachricht-----
Von: Dmitry Stogov [mailto:dmitry@zend.com]
Gesendet: Montag, 2. Februar 2015 20:14
An: Robert Stoll
Cc: PHP Internals; Andrea Faulds; Nikita Popov
Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?

Hi Dimitry,

-----Ursprüngliche Nachricht-----
Von: Dmitry Stogov [mailto:dmitry@zend.com]
Gesendet: Montag, 2. Februar 2015 10:13
An: PHP Internals; Andrea Faulds; Nikita Popov
Betreff: [PHP-DEV] What do we need strict scalar type hints for?

hi,

could you please write down few use cases, when strict scalar type
hints
are really useful.

Thanks. Dmitry.

I think strict types are beneficial in all those places where you
would put manual tests to ensure that the passed value is of a certain
type and only of this type - removing the hassle (ok, I did not add
anything to the discussion so far ^^). Right now, I mainly think of
functions which expect an int - especially in the domain of time and
money. I would expect an int and I would not want that a float can be
passed without warning and get silently converted to an int (loosing
precision in the domain of time or money can be crucial).

However, IMO it is not necessary to have a strict mode as presented by

Andrea -- I think it would be good enough if we use the same widening
rules as in Java, C# etc. and be strict otherwise. I am aware of that
with the support of BigInteger we would have a widening problem
(BigInteger to
float) but could be solved by a BigDecimal as in Clojure.

Ah... I now something I would definitely want to be strict. I guess a
typical bug, which is made by many beginners, is using the result of
strpos in an if statement without using the identity operator -- btw.
would the strict mode affect operators and control structures as well?

no. now we speak only about parameter and return value type hints.

[Robert Stoll]
Could be addressed in another RFC then.

Would somehow be the logical consequence but I suppose the impact on
performance would be too big. Or wouldn't it?

it wouldn't reduce performance. may be even increase, but it'll break every second app.

[Robert Stoll]
I wrote it a little bit ambiguously, I actually meant a negative big impact on performance. Concerning the second part of your sentence. As other already mentioned, it would not break every second app since only those apps would be concerned which enable the strict mode and even then only those files are concerned which are written by the owner of the code and the owner oneself decided to use the strict mode, ergo => everything is fine as long as the owner writes strict code and if she/he does not, then it actually must break since the owner of the file made a mistake in terms of strictness and wished to be informed about it. Makes sense no?

Back to the topic, if I expect a bool as parameter I would definitely
not want it to be automatically converted since this is a sink for bugs.

I'm not sure. If we would work on a type-safe language I would definitely agree, but PHP is a "loosely typed language" by
definition.

[Robert Stoll]
I agree, PHP is weakly typed and that is fine. Yet, if we are discussing what strict types would be useful for then the mentioned examples are good use cases IMO.
Personally, I think weak type hints as suggested in the RFC might be a way to go for PHP [*] where in a type-safe version of PHP (such as TSPHP [1]) it would not make sense at all.

[*] even though I think it is really ugly that a float or a float in a string can be passed to a function expecting an int. IMO only those values should automatically converted where it can be guaranteed that no precision is lost. Maybe I have not read the RFC carefully enough - following some examples to illustrate what I mean:

function foo(int $i){}
foo(1); //ok
foo(2.0); //still fine
foo("2"); //acceptable as well
foo('3.0'); //even this is ok

foo(1.4); //ouch
foo("1.2"); //please no
foo("1lxs"); //oh no.. please... noooo ^^

Well, yeah... I guess you get my point.

[1] http://tsphp.ch

Thanks. Dmitry.

Hope that helps.

Cheers,
Robert

--
To unsubscribe,
visit: http://www.php.net/unsub.php

Nobody would stop you from implementing a utility class Money or likewise and providing a better error message instead of using int if PHP would be strict only (what is not proposed in the RFC anyway). You could also just omit the type hint, it is entirely up to you.
The point here was that this is creating yet another set of rules that
only apply in some cases. Rather than perhaps looking at a more generic
solution that can be used in validation across all types.

There are plenty of strongly typed languages out there which work very well without the mentioned lack of specific error messages for each individual use case.
Lived with that in the past ... having to convert everything TO some
common type before using it is just as irritating. PHP's lighter touch
especially where data is coming in mainly from a string based feed is
much nicer to work with.

And btw. PHP is strict for array and class type hints as well - of course you can also omit those type hints.
Which are creating even more conflicts.

The ONE element that I am growing concerned about is a simple 64bit
BIGINT primary key which can be used as an array index. A strict integer
is heading towards some complex variable length data type, while for
probably 99.9% of database related BIGINT data it is a simple integer.
If third party libraries move towards a 'strict' style of working they
may not be efficient when used without that practice, or they may not
play nicely with other interfaces that have a different 'strict' view.
There are a growing number of low cost devices which are essentially 32
bit devices, but with 64 bit maths which is possibly incompatible with
the current 'strict' view of data within PHP.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Hi Dmitry,

I have similar opinion. Strict typing looks foreign for PHP.

It is in a way, yes. PHP has traditionally been “weakly-typed” everywhere.

That being said, we’re not always weakly-typed (there are strict type checks in some places), and userland code has sometimes done strict type checks anyway.

I see, strict type hints may be useful.
Aspecially for testing and error detection, but anyaway, I'm not sure if and how it should be enabled. Declare() is a working solution, but it's not excelent.

It’s not a perfect solution, but I haven’t seen anything that seems to be much better. The best bit about declare() is that it would make strict types completely optional, so people who don’t like them wouldn’t have to use them, even if they call code which does.

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

Hi Dmitry,

You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and implantation.
I think it may be useful for PHP7.

Thank you for the info.
It would be great to have it for PHP7 indeed.
I'm looking forward to vote.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

De : Dmitry Stogov [mailto:dmitry@zend.com]
Hi Yasuo,

You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and implantation.
I think it may be useful for PHP7.

In accordance with Yasuo's suggestions, couldn't we consider assertions as part of a future implementation of the wider 'design by contract' concept ?

DbC could handle :

• function inputs : 'smart' built-in arguments types (keeping loose typing), constraints on possible values
• function output : accepted return types/values
• assertions anywhere in the code

Function input/output validation would be done using built-in 'smart' types ('string', 'numeric', 'integer', etc), and, optionally, 'validator' functions. These could validate any aspect about argument/return type and value. The key point with DbC (as well as assertions) is that, as there's no constraint on performance, validation can be very precise and can run in userland code.

For function input/output validation, I would extend the phpdoc syntax (keeping compatibility with existing comments).

Another suggestion for assertions : if we hide it in comments (something unusual like '//@@assert(...)'), we probably don't need to define an opcode and it can be implemented as a standard function.

The question of whether DbC should replace or just supplement arg/return typing remains open :).

What I suggest, if you agree, is that, even if we don't implement the whole DbC concept now, we could already consider assertions as being part of it, and rename zend.assertions to zend.dbc, assert.exceptions to dbc.exceptions, and AssertException to DbcException.

Regards

François

Hi,

Hi Leigh,

Le 4 févr. 2015 11:50, "Leigh" leight@gmail.com a écrit :

What was wrong with:

function x(int $y, string $z) { // strict
function x((int) $y, (string) $z) { // casting

This was the best suggestion I've seen that covers the requirements of
both camps, and is still very clear how data is going to be handled.

Authors who want their APIs to adhered to strictly can do that,
authors who want to accept anything and have it end up as their
desired type can do that too.

Because it is then the callee who decides, not the caller, whether or not
he wants strict typing.

... and apparently, this is the root of all evil. :)

I am baffled by how the two-syntaxes suggestion is always so easily
dismissed by that argument. I'd argue that most people who support the
current proposal don't fully understand what declare(strict_type=1)
really does. As I've previously said - putting the caller in control
(and really the caller, not in a per-file context) makes it a
debugging tool, not support for strict typing.

Cheers,
Andrey.

Because it is then the callee who decides, not the caller, whether or not he
wants strict typing.

And that is the way it should be.