Hi,

I would like a way of enabling strict by
default, immutable to scripts so that users cannot be forced into this
mode, and lets the radicals and the weaklings* play together in
harmony.

For the rest of the RFC, I either agree with or have no strong
opinions about the points raised.

*it's a joke you guys.

I am still bipolar and I still want both to co-exist with no switches
and modes. :)

No joke.

Cheers,
Andrey.

Leigh,

Internal Functions Like ceil() Return Unexpected Types

My opinion is that functions should return sane types for their
intended purpose, and functions that do not should be "fixed".

I agree 100%. I just think that's outside the scope of this proposal.

Static Analysis Is Possible With Weak Declarations

The advocacy of allowing accepts_float(returns_int()); doesn't help
the cause of static analysers in strict mode.

Java does exactly this and is statically analyzable. So...?

Still no mention of a way to enable strict by default. So lets try
some different rationale. If I personally want to develop in strict
mode, I can do that with this proposal, I can add a declare to the top
of every file and be as strict as I like. However not everyone else is
going to want to use my code in strict mode, so they will have to go
and remove some/all of those strict declarations. (Lets take callbacks
being evaluated in the context they are called rather than the one
they are created in). I would like a way of enabling strict by
default, immutable to scripts so that users cannot be forced into this
mode, and lets the radicals and the weaklings* play together in
harmony.

I missed that discussion point, so I've just added it:
https://wiki.php.net/rfc/scalar_type_hints_v5#why_not_add_an_ini_setting_for_default_mode

For the rest of the RFC, I either agree with or have no strong
opinions about the points raised.

Thanks for the input :-)

Anthony

On 18 February 2015 at 22:21, Albert Casademont Filella
albertcasademont@gmail.com wrote:

So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.

This is pretty flawed, but nice try.

Albert,

On Wed, Feb 18, 2015 at 5:21 PM, Albert Casademont Filella
albertcasademont@gmail.com wrote:

Hi Anthony!

Thanks for bringing this up again. I am asking you the same I asked Andrea 2
weeks ago on Twitter: make it a triple option vote please. She didn't want
to do it, hope you do! This way you eliminate the neverending discussion
about weak vs strict, let the votes decide and see who really prefers weak
type hinting only and who prefers the stricter way, both camps will have an
option to vote.

So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.

Thanks for the feedback. I have added it to the discussion points:
https://wiki.php.net/rfc/scalar_type_hints_v5#this_proposal_should_have_multiple_vote_options

The text:

This is not a two-part proposal. The proposal is of a unified system
that was designed to work together. As such, neither part (weak-only
or strict-only) is designed to stand on its own without the other
part.

Therefore, it only makes sense to vote on this proposal as a whole.
Therefore, the voting options this RFC will present will be: Yes and
No.

Thanks,

Anthony

Christoph,

Anthony Ferrara wrote:

3. int typed variables can resolve a parameter type of float So
   calling requiresAFloat(10) will work even in strict mode.

Have you considered the overflow behavior of ints resulting in a float?
For instance, the following code would produce E_RECOVERABLE_ERROR, AIUI:

<?php

declare(strict_types=1);

function foo(int a, int b) {
bar(a * b);
}

function bar(int n) {
}

foo(10000000000, 10000000000);

It seems to me that this behavior is hard to deal with generally for
programmers as well as static analyzers. Andreas' bigint RFC[1] would
solve that issue, but it has been withdrawn, and AFAIK nobody is working
on it. OTOH, bigint would make the widening from int to float
potentially even more lossy (i.e. inaccurate) than it is now (64bit ints
vs. IEEE 754 doubles).

IIRC, Pascal does not promote int to float on overflow, but rather
discards the high bits (unless overflow checking is enabled; available
only in some "newer" dialects). I don't know how Java handles this
case, but I assume there's no promotion to float either.

[1] https://wiki.php.net/rfc/bigint

That is a very good point. We had discussed that a while ago, but it
hasn't come up in a while here. I've added a section in the RFC on it:
https://wiki.php.net/rfc/scalar_type_hints_v5#integer_overflow_to_float_behavior

Basically, I don't see any sane alternative but to have it cause an
error at runtime. It's not precision loss, it's magnitude loss.

The only other thing I can think of is to have the operators not
promote in strict mode, but that's even worse since now you're
clamping and not even giving the ability to detect it.

I don't think in practice it will be a huge issue, but even if it
comes up, it'll at least error sanely...

Thanks

Anthony

It seems to me that this behavior is hard to deal with generally for
programmers as well as static analyzers. Andreas' bigint RFC[1] would
solve that issue, but it has been withdrawn, and AFAIK nobody is working
on it. OTOH, bigint would make the widening from int to float
potentially even more lossy (i.e. inaccurate) than it is now (64bit ints
vs. IEEE 754 doubles).

The 'unconstrained integer' RFC adds it' own problems, but the int ->
float overflow is only a problem with 32bit builds anyway. 64bit builds
will not overflow until they run out of space anyway.

--
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

Am 19.02.2015 um 05:21 schrieb Dennis Birkholz:

Am 18.02.2015 um 21:44 schrieb Anthony Ferrara:

Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes being only due to reasonably minor issues with the proposal,
I would like to re-propose her RFC with three minor modifications:

What about Sara's "Scalar Type Hints v0.4" discussion? I find it
disturbing that you take over the RFC without even mentioning this
discussion. Please coordinate with Sara first before starting another
attempt that will be doomed because some people rather wait for Sara's
RFC and a "<?php // strict" option.

I just saw the reddit where you mention that v0.4 is practically
abandoned now, so I will just renounce my previous mail!

Will you consider to let the people vote on how to enable strict mode
like discussed in the v0.4 discussion? Like this here from the "Reviving
scalar type hints" thread?

Am 17.02.2015 um 00:58 schrieb Sara Golemon:> Straw poll:

1. <?php strict;
2. <?php-strict
3. use strict; (psuedo-namespace)
4. <?php // strict (I don't actually like HHVM's style, but if you do...)
5. declare(strict=true); (As a top-level declare only)
6. declare(strict=true); (exactly as in v0.3 -- maybe you liked it)
7. your write-in vote here

Thanks
Dennis

Robert,

you wrote: "aliases are removed (integer and boolean)"
what about the aliases real and double?

They were never part of Andrea's proposal. So they were never accepted anyway.

You wrote: "behaviour of weak type checks: float -> int *Only non-NaN floats between PHP_INT_MIN and PHP_INT_MAX accepted. (New in PHP 7, see the ZPP Failure on Overflow RFC)"
What about INF? Can INF be passed or not and if so, how is it converted?

Please see the other RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow

Namely: The special floating-point values INF and -INF fail the check
like any other number that is too large.

Personally I would be stricter and disallow int->bool, float->bool, string->bool as well as bool -> int, bool -> float and bool -> string (at least for this RFC)
Why?

1. I already mentioned the common if(strpos(..)){} case but is something which none of the RFC addressed so far and probably goes too far (you wrote "In addition to userland functions, the strict type checking mode also affects extension and built-in PHP functions:" but control structures are not affected, right?)

This only affects function calls. Not control structures.

2. It supports an inconsistency in PHP which we should try to get away with rather than promoting it. Following an example:

function foo(string $x){
var_dump($x);
bar($x);
}
function bar(bool $x){
var_dump($x);
baz($x);
}
function baz(string $x){
var_dump($x);}
foo(0);

and the output would be:

string(1) "0"
bool(false)
string(0) ""

Sure, removing the implicit conversions from and to bool do not pretend that the same would happen if one uses manual conversions instead. Yet, IMO we should forbid the implicit conversion from and to bool now and add it later on with consistent conversion rules. This way we have more time to think about a clean solution and adding implicit conversion from and to bool should also not be a BC break in 7.1

Simple: don't use weak mode. This proposal does not invent the weak
mode rules, it simply exposes them from ZPP (how it's implemented in
all internal functions) to userland hints.

So any change there would be outside of scope for this proposal and
should be made as another proposal. I will add this to the discussion
points section.

Another example:

function foo(int $x){
var_dump($x);
bar($x);
}
function bar(string $x){
var_dump($x);
}
foo(false);
bar(false);

and output:

int(0)
string(1) "0"
string(0) ""

I think you get the inconsistency I am writing about.

About widening. It is not clear from the RFC if widening is only applied for int -> float or also for bool -> int, bool -> float respectively.

It's explicitly stated: "This means that parameters that declare float
can also accept int."

I will clarify this as well.

Thanks!

Anthony

All,

An interesting point was brought up related to block mode:
https://twitter.com/drrotmos/status/568540722586107904

Namely that generated file caches may need the ability to switch block
mode on-and-off.

I'm considering making the change to add that. If that happens,
declare must be the outermost block, and no non-declare blocks would
be allowed in the outermost scope of the file:

<?php
declare(strict_types=1) {
//...
}
declare(strict_types=0) {
//...
}

Having trailing code or code outside of the declare would be a compile error.

<?php
declare(strict_types=1) {
//...
}
foo(); // compile error

This behaves consistent with namespace block-mode today (though the
strict type declaration would be required to be outside the namespace
block).

I'm considering adding it, as it's a valid use-case. What do you think?

Seems a valid use case, and the block solution is therefore the
logical step. I see no reason to exclude it.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

All,

An interesting point was brought up related to block mode:
https://twitter.com/drrotmos/status/568540722586107904

Namely that generated file caches may need the ability to switch block
mode on-and-off.

I'm considering making the change to add that. If that happens,
declare must be the outermost block, and no non-declare blocks would
be allowed in the outermost scope of the file:

<?php
declare(strict_types=1) {
//...
}
declare(strict_types=0) {
//...
}

Having trailing code or code outside of the declare would be a compile error.

<?php
declare(strict_types=1) {
//...
}
foo(); // compile error

This behaves consistent with namespace block-mode today (though the
strict type declaration would be required to be outside the namespace
block).

I'm considering adding it, as it's a valid use-case. What do you think?

So, I ran into a snag while doing this.

It turns out that in the parser implementation of declare is not going
to allow it without significant restructuring (including a lot of
validation in the compiler):

declare_statement:
statement { $$ = $1; }
| ':' inner_statement_list T_ENDDECLARE ';' { $$ = $2; }
;

So in block mode, declare supports inline, block and named-block mode:

declare(...) foo();
declare(...) {
foo();
}
declare(...):
foo();
enddeclare;

The problem with this is that namespace declarations can only happen
in top_statement (along with some other statements).

That leaves two options to support multiple modes per file:

1. Allow in top-level only:

declare(strict_types=1);
namespace Foo {
}
declare(strict_types=0);
namespace Bar {
}

2. inside of the namespace:
   namespace Foo {
   declare(strict_types=1);
   }
   namespace Bar {
   }

The problem with the first is clarity (it's easy to miss a declare and
not understand that the mode has changed). We pinned declare to the
top of the file for clarity. I'm not sure this use-case is worth
breaking that clarity.

The problem with the second is more subtle. With the current
parser+compiler, that declare would affect the entire file. It would
take pretty significant changes and restructuring of the parser to
effect.

We could drop declare() all together and go with something like a
namespace modifier:

strict namespace Foo {
}
namespace Bar {
}

But I don't think it's worth it to conflate those two together. Though
if we did, the syntax "strict namespace;" would be supported for
non-namespaced strict code.

So in the end, my conclusion is that while it would be nice to support
the "compiled file" use-case fully, it's not worth it from a technical
level (the risk and degree of change required doesn't offset the
benefit of it).

So the proposal will remain unchainged and not support the block
syntax (or changing the mode mid-file).

Thanks

Anthony

Chris,

I'll edit in the proposal, but you can check the tests in the mean time:

https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_002.phpt
https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_004.phpt
https://github.com/ircmaxell/php-src/blob/c8590799622ddb801360664d08ac5d7f4fa342df/Zend/tests/typehints/scalar_strict_declaration_placement_005.phpt

So it needs to come before the namespace declaration (in fact, it
currently needs to be the first declaration in the file).

Though I am about to implement the block syntax, and that may alter
things slightly (though declare will be required to be outside the
namespace).

Anthony

Hi Anthony,

I have been interested in this proposal for a while now. I'm not on internals, but I have a question about your proposal.

1. declare(strict_types=1) (if used) is required to be the first
   instruction in the file only. No other usages allowed.

How would this work with namespaces?

declare(strict_types=1) namespace Foo;

namespace Bar; declare(strict_types=1)

strict namespace Baz;

Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP.

Cheers,

Chris