Re: What do we need strict scalar type hints for?

Hi Andrea, On Wed, Feb 4, 2015 at 8:21 PM, Andrea Faulds <ajf@ajf.me> wrote: > Hi again, > >> On 4 Feb 2015, at 11:15, Andrey Andreev <narf@devilix.net> wrote: >> >> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine <florian@margaine.com> wrote: >>> 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. :) > > It’s not “the root of all evil". But the two-syntax approach has disadvantages I’ve > elaborated numerous times. > > It shifts the choice to the callee, not the caller. This means existing applications are broken > if strict hints are added to existing libraries. It means that programmers will have to deal with > two different systems, simultaneously, in the same file or function or method, because one API uses > (int) and the other uses int. It means that if the API author decides to have weak types, you are > prevented by the language from having the benefits of strict typing, even if you want them. It also > has a syntax issue: (int) looks like an explicit cast, yet what is usually proposed doesn’t > something similar. There’s also the consistency issue in that we’d have to support real for > consistency with (real), since T_DOUBLE_CAST is a token. It means that internal functions could now > also use strict hints - or if they can’t, we have a consistency issue. It means beginners, and > people who don’t like strict types, now have to deal with strict types in their code, despite PHP > always having been a weakly-typed, beginner-friendly language. And so on, and so forth. > > The current RFC deliberately does not propose this because I think it causes more problems then > it solves. > >> 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. > > Well, *I* understand what it does. That's an own goal (in football/soccer terms), you know. ;) > I’ve used it. It worked really, fantastically well… better than I expected it to. It > provided benefits that the two-syntax suggestion wouldn’t have. It provided benefits that just > strict hints wouldn’t have. It provided benefits that just weak hints wouldn’t have. > >> 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. > > What’s the difference between “per-file” and “really the caller”? The RFC *does* > allow you to use declare() blocks if you really want to. > > Also, type hints are mostly a debugging tool anyway. They’re a tool for catching errors > early, and to enable better documentation. That’s all that they do. > Yeah, you've said that numerous times ... almost as much as I have disagreed with your arguments. I didn't want to turn this thread into a re-iteration of the RFC discussion one. I'm just completely surprised how relentlessly all suggestions about two syntaxes have been waved off by a callee vs caller argument like it's a golden rule or something ... it's not, you just don't like the other approach. Cheers, Andrey.