# A plea for unity on scalar types

- Thread: https://externals.io/message/84714
- Original archive: https://news-web.php.net/php.internals/84714
- Started by Scott Arciszewski on 2015-03-13T19:51:30+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #84714 — Scott Arciszewski — 2015-03-13T19:51:30+00:00

URL: https://externals.io/message/84714#84714

Pavel_Kouřil wrote:

> - It is a "setting" that changes the language's behavior; I don't
> think that it matters whether or not it would be an INI setting or the
> declare() one, because both of them are bad.
>
> It allows people who want strict typing to declare it on a per-PHP-file
basis. An INI setting cannot offer this guarantee. This is required if weak
and strict are to be both supported.

> - It does not "unite different usages of PHP into a single group"; it
> does exactly the opposite, splitting PHP usage into TWO groups.
>
> It also allows the two groups to work together rather than forking PHP
into separate languages: PHPstrict and PHPweak.

> - Once this dual mode would be introduced to PHP, there would probably
> be no way of removing it later without massive BC break, once most
> people would realize that it is really awful to have it in the
> language.
>
> What is "really awful" about this? Moving forward, everything could move
towards strict typing. I could see PHP 8 or 9 having strict be the default,
if everyone wanted that. And then the declare() being deprecated and
removed as major versions increase.

Scott

---

## #84808 — pajousek@gmail.com — 2015-03-15T08:42:29+00:00

URL: https://externals.io/message/84714#84808 · In reply to: #84714

>  Pavel_Kouřil wrote:
>
> > […]
> basis. An INI setting cannot offer this guarantee. This is required if weak
> and strict are to be both supported.
>
> > […]
> into separate languages: PHPstrict and PHPweak.
>
> > […]
> towards strict typing. I could see PHP 8 or 9 having strict be the default,
> if everyone wanted that. And then the declare() being deprecated and
> removed as major versions increase.
>
> Scott

Hello,

I'm sorry, I totally overlooked your email, so I'm replying with a little delay.

Sure, per-file is better than ini setting, but better doesn't mean
good (because it is still a pretty bad approach). The ini setting at
least has the option to be turned off in code once everyone realizes
it was a bad idea (register_globals via htaccess, for instance), but
PHP would be stuck with the declare for a long time - this is not an
easily revertable change, once PHP ships with it.

The two groups (people who want strong typing and weak typing) will
not work *together* though. And it will be a nightmare for everyone
working on multiple projects from mulitple clients or so.

PHP will IMHO never be strongly-typed by default. It would break BC so
much it's not just possible. The best approach to have some reasonable
type rules is to progressively "strenghten" the rules (as Zeev's RFC
tried to do so, but he probably did two steps in one RFC and that's
what people dislike about it?). I think that PHP's type system would
get to some "equilibrium" by this - people wanting stronger typing
would tried to introduce it and people wanting weaker one would
balance it and eventually there could be a point on which both sides
could agree on.

I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
RFC being good for the userland developers in the long run.

Regards
Pavel Kouril

---

## #84809 — Leigh — 2015-03-15T08:56:04+00:00

URL: https://externals.io/message/84714#84809 · In reply to: #84808

> Sure, per-file is better than ini setting, but better doesn't mean
> good (because it is still a pretty bad approach). The ini setting at
> least has the option to be turned off in code once everyone realizes
> it was a bad idea (register_globals via htaccess, for instance), but
> PHP would be stuck with the declare for a long time - this is not an
> easily revertable change, once PHP ships with it.
>

The declaration is turned on with code. This is no different to changing an
ini setting with code, except that it can't be configured globally in
advance.

Existing code is unaffected. I'm not sure where your "not easily
revertible" argument is grounded. It's incredibly easy to add/remove
declarations at the top of a file.

The two groups (people who want strong typing and weak typing) will
> not work *together* though. And it will be a nightmare for everyone
> working on multiple projects from mulitple clients or so.
>

Pure FUD. Sorry but there is no evidence to back this up.

PHP will IMHO never be strongly-typed by default.


Probably.


> The best approach to have some reasonable
> type rules is to progressively "strenghten" the rules (as Zeev's RFC
> tried to do so, but he probably did two steps in one RFC and that's
> what people dislike about it?).


You think the best approach is to progressively and continually break
working code between versions? How is this approach acceptable ever?


> I think that PHP's type system would
> get to some "equilibrium" by this - people wanting stronger typing
> would tried to introduce it and people wanting weaker one would
> balance it and eventually there could be a point on which both sides
> could agree on.
>

No, they would never reach agreement.

I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
> RFC being good for the userland developers in the long run.


Apologies again, but I think you don't really understand what is being
proposed in this RFC. Proponents of strict typing get exactly what they
want, they can develop their library or entire project in strict mode if
they want, and if someone wants to use this project or library, but
themselves want to use weak mode, _nothing breaks_.

---

## #84811 — pajousek@gmail.com — 2015-03-15T09:52:52+00:00

URL: https://externals.io/message/84714#84811 · In reply to: #84809

>
> 
> > […]
>
>
> The declaration is turned on with code. This is no different to changing an
> ini setting with code, except that it can't be configured globally in
> advance.
>
> Existing code is unaffected. I'm not sure where your "not easily revertible"
> argument is grounded. It's incredibly easy to add/remove declarations at the
> top of a file.
>

So - are you saying that it would be easy to remove this feature from
the language once people would realize it's register_globals (and any
other settings that change how code behaves) all over again?

> > […]
>
>
> Pure FUD. Sorry but there is no evidence to back this up.
>

Well, how can there be evidence when the feature isn't released yet?
But if you read through the discussions about the Dual Mode RFCs,
you'll see that I'm definitely not the only userland developer with
this opinion.

Also, I can't think of any other language (apart from JS) which has
some settings that change how the code behaves. I'd guess most
languages don't do this for good reasons, but who knows, can't say for
sure.

>
> > […]
>
>
> You think the best approach is to progressively and continually break
> working code between versions? How is this approach acceptable ever?
>

This of course doesn't mean breaking existing code in every version. I
doubt there would be more than 2 or 3 changes to the conversion rules
in foreseeable future with this approach. But I do agree that this
isn't ideal way to do things, but I'd say it's the right one.

> > […]
>
>
> No, they would never reach agreement.
>

"Pure FUD. Sorry but there is no evidence to back this up. "

(Sorry, I had to - I really do believe that some consensus would be
reached after a while, though.)

> > […]
>
>
> Apologies again, but I think you don't really understand what is being
> proposed in this RFC. Proponents of strict typing get exactly what they
> want, they can develop their library or entire project in strict mode if
> they want, and if someone wants to use this project or library, but
> themselves want to use weak mode, _nothing breaks_.
>

Why does everyone reply to the disagreeing opinions with "I think you
don't understand the RFC"? I've seen this happen multiple times in the
discussions with Dual Mode RFC, even when the person understood the
RFC. I am 100% aware that the caller decides the rules, not the callee
and that there's supposed to be interoperability - and yet, I still
strongly disagree with it, mostly because it makes managing multiple
projects (each working with different mode) harder.

I would generally love to have type hints in PHP 7.0 (with any
reasonable ruleset, be it strongly typed, weakly typed or some middle
ground, I don't care as long as it's only *one* ruleset), but I would
rather have none than the Dual Mode one.

Regards
Pavel Kouril

---

## #84821 — Scott Arciszewski — 2015-03-15T12:25:07+00:00

URL: https://externals.io/message/84714#84821 · In reply to: #84811

>
> 
> > […]
changing an
> > […]
revertible"
> > […]
at the
> > […]
>
> So - are you saying that it would be easy to remove this feature from
> the language once people would realize it's register_globals (and any
> other settings that change how code behaves) all over again?
>
> > […]
>
> Well, how can there be evidence when the feature isn't released yet?
> But if you read through the discussions about the Dual Mode RFCs,
> you'll see that I'm definitely not the only userland developer with
> this opinion.
>
> Also, I can't think of any other language (apart from JS) which has
> some settings that change how the code behaves. I'd guess most
> languages don't do this for good reasons, but who knows, can't say for
> sure.
>
> > […]
>
> This of course doesn't mean breaking existing code in every version. I
> doubt there would be more than 2 or 3 changes to the conversion rules
> in foreseeable future with this approach. But I do agree that this
> isn't ideal way to do things, but I'd say it's the right one.
>
> > […]
>
> "Pure FUD. Sorry but there is no evidence to back this up. "
>
> (Sorry, I had to - I really do believe that some consensus would be
> reached after a while, though.)
>
> > […]
>
> Why does everyone reply to the disagreeing opinions with "I think you
> don't understand the RFC"? I've seen this happen multiple times in the
> discussions with Dual Mode RFC, even when the person understood the
> RFC. I am 100% aware that the caller decides the rules, not the callee
> and that there's supposed to be interoperability - and yet, I still
> strongly disagree with it, mostly because it makes managing multiple
> projects (each working with different mode) harder.
>
> I would generally love to have type hints in PHP 7.0 (with any
> reasonable ruleset, be it strongly typed, weakly typed or some middle
> ground, I don't care as long as it's only *one* ruleset), but I would
> rather have none than the Dual Mode one.
>
> Regards
> Pavel Kouril

Interoperability issues? With an optional language feature? Riiiight

---

## #84825 — Matthew Leverton — 2015-03-15T14:10:48+00:00

URL: https://externals.io/message/84714#84825 · In reply to: #84811

> So - are you saying that it would be easy to remove this feature from
> the language once people would realize it's register_globals (and any
> other settings that change how code behaves) all over again?
>

Actually, it would be very easy to remove this from the language.
There is no possible way to rely on strict hints over auto-cast hints
in such a way that would break your application by any meaningful
definition of the word.

<?php
declare(strict_types=1);

function foo(int $i) : int
{
  if (!is_int($i)) die('How did we get here?');
  return $i + 1;
}

echo foo("1");
?>

Output, after strict_types has been removed from language:

E_NOTICE: strict_types is no longer supported.
2

Yes, that would have previously thrown an exception, but the behavior
after removing strict types from the language really hasn't broken
anything. This is nothing like removing register_globals... where
entire apps silently break without any good way to track down how and
where.

Honestly, I think the reverse of your scenario is more likely.

1) Only the "strict_types=0" mode is implemented, using same rules as
standard PHP casts. (basic_scalar_types)

2) xdebug adds a feature to enable the equivalent of strict_types=1
for debug mode.

3) People realize this is super useful and request "please allow a
whitelist while debugging so I can debug my app in pieces" and ask
"how can we optionally enable this during production mode?"

4) declare(strict_types=1) is proposed for support in PHP without
xdebug, and is accepted.

:)

Finally, the voting process on these two RFCs is absurd, and even more
absurd with the proposal of a third one. Very few people are going to
play fair and vote YES on multiple of them, even if they would vote
YES if it was the only proposal. As I've said before, the best way to
reach consensus on *large, grand ideas* (i.e., not petty details) is
to hold an instant runoff on a single vote. e.g., Rank your choices in
order of preference: scalar_type_hints_v5, coercive_sth,
basic_scalar_types, none. First to 2/3's win, after eliminating the
least popular vote each round. (Could still end up with a winner <
2/3s, which would just mean the RFC failed.) I sincerely hope this
type of vote is added as an option for future RFCs when appropriate,
so that we never have to go through this terrible process again.

(PS: I have nothing against the RFC authors; on the contrary, I
respect all of the work they have put into their proposals. So big
thanks to all of you!)

--
Matthew Leverton