Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101526 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73447 invoked from network); 3 Jan 2018 20:26:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2018 20:26:33 -0000 Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.46 mail-wm0-f46.google.com Received: from [74.125.82.46] ([74.125.82.46:33464] helo=mail-wm0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/A5-23177-67C3D4A5 for ; Wed, 03 Jan 2018 15:26:31 -0500 Received: by mail-wm0-f46.google.com with SMTP id g130so21630677wme.0 for ; Wed, 03 Jan 2018 12:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=mNY7DpO6PAovkaWlsasGzyEUyWG3z6mAoLyupqxfCS8=; b=USrOfvvKU8jDMX+yDsPv9leVxwIgEThP3Els+irYB3N+vb5QJ4+05xcpjHENGY3ac9 6xcndM4rxwfVqzJ6ll72ByYVvlUs8Bm0PP/iOlEklCvXgK67D2qfuwy34n0iledmEC9a 2/p9QVJEFqfHThAD3SRSjPUrYYPLQdsX62BXS4LCWtyoe3PXxrREpv7rvggVQRu7UIpx ZWbeDL+LaHRzvAtR2TUcVwEw7ql9hnQRx5bX0ZgmnmjagO+TgOC93D4hOAw3AefHw/7o eYv+EnrJ5NUCw9PUQsGLl/P8yNxKOfeKd2GZ+pZAjJdaFnAJzJKOMh2b8NLboncpKO/T NTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=mNY7DpO6PAovkaWlsasGzyEUyWG3z6mAoLyupqxfCS8=; b=YXHPqYV/MOm8UuoQycvY/iPCdYTjVIcxTKQ+bJJeRnfJv1A83hHVk2CpjXiV2q4Svx UKiPNOMUAbY9nA/ygikIeS6uyV8tmMXsFiliUGJUpo2jCepbfamhUr2HbSbVVmQ2wkOS typ3spg2IoYNmay7Ngia+1jTUOGY3izmrjAvzyaRQGNtBXE4PuRLbXyiu8NBQjt+Q9Ks djbmMyAJ7RTSf/H0Uk0Hrue/b8eYLc8eC7IMSuXtkiN/7CPqN20QfkYhHe9B2sKraovl iQk+Rbh1JzF2H/eAotfMyXQO1Y5KHnWCzmodCuHn3iULppddGnt3B73WbM8OmmV+4u1r XzIw== X-Gm-Message-State: AKGB3mJC1C9ZS4W3BkhMsMY+fqvKAeJForvsjizNOPPXxArepW4AZaJW 98zNeocqidWOeibzzJBiEgl7bw== X-Google-Smtp-Source: ACJfBovC6J/d9rYEtrxt0Wvjngsttu8KCR5D8gT20+pn2xles7r8rorQF9HUDVe4hqreWzMcdZ51/Q== X-Received: by 10.28.249.1 with SMTP id x1mr2521948wmh.138.1515011186721; Wed, 03 Jan 2018 12:26:26 -0800 (PST) Received: from ?IPv6:2a00:23c4:4b81:ae00:e5e6:db73:a:b9ee? ([2a00:23c4:4b81:ae00:e5e6:db73:a:b9ee]) by smtp.googlemail.com with ESMTPSA id 194sm1858882wmu.37.2018.01.03.12.26.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 12:26:26 -0800 (PST) To: internals@lists.php.net References: Message-ID: <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> Date: Wed, 3 Jan 2018 20:26:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax From: rowan.collins@gmail.com (Rowan Collins) Hi Michael, On 02/01/2018 10:35, Michael Morris wrote: > I would like to propose a clean way to add some strong typing to PHP in a > manner that is almost fully backward compatible (there is a behavior change > with PHP 7 type declarations). As I don't have access to the add RFC's to > the wiki I'll place this here. Thanks for putting this together. Perhaps unlike Andreas, I think it is good to look at typing changes as a unified framework, rather than considering "typed properties", "typed variables", etc, as separate concerns. If we don't, there is a real risk we'll end up making decisions now that hobble us for future changes, or over-complicating things in one area because we're not yet ready to make changes in another. My own thoughts on the subject from a while ago are here: http://rwec.co.uk/q/php-type-system In that post, I borrowed the term "container" from Perl6 for the conceptual thing that type constraints are stored against; in PHP's case, this would include variables, object properties, class static properties, function parameters, and return values. I think a good plan for introducing typing is one that considers all of these as equals. The biggest issue with any proposal, though, is going to be performance. I don't think this is an incidental detail to be dealt with later, it is a fundamental issue with the way type hints in PHP have evolved. PHP is extremely unusual, if not unique, in exclusively enforcing type constraints at runtime. Other languages with "gradual typing" such as Python, Hack, and Dart, use the annotations only in separate static analysers and/or when a runtime debug flag is set (similar to enabling assertions). Extending that to all containers means every assignment operation would effectively need to check the value on the right-hand-side against the constraint on the left-hand-side. Some of those checks are non-trivial, e.g. class/interface constraints, callable; or in future maybe "array of Foo", "Foo | Bar | int", "Foo & Bar", etc. There are ways to ease this a bit, like passing around a cache of type constraints a value has passed, but I think we should consider whether the "always-on runtime assertions" model is the one we want in the long term. > If the type is omitted, scalar is assumed. As Andreas pointed out, you mean "mixed" here (accepts any value), rather than "scalar" (accepts int, string, float, and bool). > The variables created by this pattern auto cast anything assigned to them > without pitching an error. My initial thought was that this makes the assignment operator a bit too magic for my taste. It's conceptually similar to the "weak mode" for scalar type hints (and could perhaps use the same setting), but those feel less magic because they happen at a clear scope boundary, and the cast only happens once. But on reflection, the consistency makes sense, and assigning to an object property defined by another library is similar to calling a method defined by another library, so the separation of caller and callee has similar justification. > PHP 7 introduced type declarations. This is incorrect, and leads you to a false conclusion. PHP 7 introduced *scalar* type declarations, which extended an existing system which had been there for years, supporting classes, interfaces, the generic "array" constraint, and later pseudo-types like "callable". I don't think it's tenable to change the meaning of this syntax, but it would certainly be possible to bikeshed some modifier to simultaneously declare "check type on function call, and declare corresponding local variable as fixed type". > OBJECT TYPE LOCKING > > [...] > > QUESTION: How do we handle the second auto casting case? $a is not allowed > to not be a SomeClass() object, but there are no casting rules. There are actually more than just object and scalar type hints - "callable" is a particularly complex check - but currently they all just act as assertions, so it would be perfectly consistent for "locking" to also only have the one mode. > COMPARISON BEHAVIOR > When a strongly typed variable (autocasting or not) is compared to a scalar > variable only the scalar switches types. The strict comparison operator is > allowed though it only blocks the movement of the scalar. > > Comparisons between strongly typed variables are always strict and a > TypeError results if their types don't match. This actually provides a way > to force the greater than, lesser than, and spaceship operation to be > strict. I like this idea. The over-eager coercion in comparisons is a common criticism of PHP. In general I really like the outline of this; there's a lot of details to work out, but we have to start somewhere. Regards, -- Rowan Collins [IMSoP]