A plea for unity on scalar types

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.

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?

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.

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.

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?

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.

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.

"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.)

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.

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

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