Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101509 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45328 invoked from network); 3 Jan 2018 17:10:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2018 17:10:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=andreas@dqxtech.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=andreas@dqxtech.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.53 cause and error) X-PHP-List-Original-Sender: andreas@dqxtech.net X-Host-Fingerprint: 209.85.215.53 mail-lf0-f53.google.com Received: from [209.85.215.53] ([209.85.215.53:42906] helo=mail-lf0-f53.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/EF-23177-C9E0D4A5 for ; Wed, 03 Jan 2018 12:10:54 -0500 Received: by mail-lf0-f53.google.com with SMTP id e27so2367431lfb.9 for ; Wed, 03 Jan 2018 09:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pfHIk4mqLKnCl4Q5hI7L8F7fol2lqMeWpRkjuUB+NhY=; b=st5KzDn49878PtK1MZrSkjfh4KuSx/W5o/LTFWb2knvJa/M694asDvYyNXaNz/42dm HRxNG0bPY9xGzCRI/nXqwed/8iaMPmD5kWXMj+zfc7LT12ObUkfBaytxxEflr9WD0/Sx 1CELKoiSiFmX0iQRW/tkdApMJeb3hwpe2otpHJrbinfX6kbOE1a9pbjLbOGb6Oi3jLZc QH9xBaYR0u35i5IOSieyVFG67uWac5kK/FExflePdJAnI+Ri4f6YCvkpMe8EWxTfM4pp Jrb89Z8pgMupHmlfhOiiNOVA59kcNnrZn5+dFhg7flrgiBHXhfflDNF4GQr04MDf3dDR 9Grg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pfHIk4mqLKnCl4Q5hI7L8F7fol2lqMeWpRkjuUB+NhY=; b=aLdBD4wxq0E8pupBDyUfFl2IYfdyQDZZ389VVCh/NyVbyfBQ8D8aHo9Eb93cBv6BzF o8okPg1CftIYOfpj9V8JT/XwIj1q09BrIVBX6BGFAU7Fz+12QfDZ8XUgq0hfYgAvUtf7 nE0BD1NsuKhgtOsiGMLIP20vgeNHwqHE7pJqg7uKTwX1Va62sGXDaNMKYr2wVojZVGBx Rb57kR9aUk+fCl67DUk7T28Z0t8nq9B7mTN3LVR1HMLuAOJnR7FEmM96hJKwPD9Q5gCh iUfxrblAGOeMWXEeDtms3CWM2qzihyTnxkEvIoXdu04YFM3d6TAlsKExJxLcpCinYhlY L+sw== X-Gm-Message-State: AKGB3mI16I5TEmnhOOE9EvW3Lyn01SVfycV4wiST3PrzeD1paQiKxXgD Gz1FwvqmDAtQpiXYKH9dYcraxn2U X-Google-Smtp-Source: ACJfBos4E+J1N/2VWrRGrGLU0Sv3tRL5fV2+0ubj5pVgwcbLA1XhfWszf+BPzmXFhoFtVimZ8lDaFw== X-Received: by 10.46.68.11 with SMTP id r11mr1302924lja.1.1514999449181; Wed, 03 Jan 2018 09:10:49 -0800 (PST) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. [209.85.215.48]) by smtp.googlemail.com with ESMTPSA id p40sm272149lfg.79.2018.01.03.09.10.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 09:10:48 -0800 (PST) Received: by mail-lf0-f48.google.com with SMTP id o26so2362935lfc.10 for ; Wed, 03 Jan 2018 09:10:47 -0800 (PST) X-Received: by 10.46.75.9 with SMTP id y9mr1247435lja.57.1514999447653; Wed, 03 Jan 2018 09:10:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.201.210 with HTTP; Wed, 3 Jan 2018 09:10:26 -0800 (PST) In-Reply-To: References: Date: Wed, 3 Jan 2018 18:10:26 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Michael Morris Cc: Niklas Keller , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax From: andreas@dqxtech.net (Andreas Hennings) This proposal contains some interesting ideas, which I see as separate: 1. A syntax to declare the type of local variables. 2. A syntax to declare the type of object properties. 3. Preventing local variables, object properties and parameters to change their type after initialization/declaration. For me the point 3 is the most interesting one. I think the other points are already discussed elsewhere in some way, although they are clearly related to 3. Point 3 would be a BC break, if we would introduce it for parameters. Current behavior: https://3v4l.org/bjaLQ Local variables and object properties currently cannot be types, so point 3 would not be a BC break for them, if we introduce it together with 1 and 2. But then we would have an inconsistency between parameters and local vars / object properties. What we could do to avoid BC break is to introduce declare(fixed_parameter_types=1) in addition to declare(strict_types=1). For local variables and object properties, the type would always be fixed. But for parameters, it would only be fixed if the declare(fixed_parameter_types=1) is active. Maybe to make it less verbose, we could say declare(strict_types=2), which would mean the combination of both those things? Or some other type of shortcut. I think we will have to think about shortcuts like this if we introduce more "modes" in the future. > Currently the var keyword is used to formally declare a variable. Are you talking about local variables? In which PHP version? https://3v4l.org/o0PFg Afaik, currently var is only used for class/object properties from the time when people did not declare the visibility as public/protected/private. > If the type is omitted, scalar is assumed. If Fleshgrinder's scalar RFC is > accepted then it would make sense to allow programmers to explicitly > declare the variable as a scalar, but in any event when the type is omitted > scalar must be assumed for backwards compatibility. If no type is specified, then "mixed" should be assumed, not "scalar". Assuming "scalar" would be a BC break, and it would be confusing. On 3 January 2018 at 10:03, Michael Morris wrote: > On Wed, Jan 3, 2018 at 3:50 AM, Niklas Keller wrote: > >> Hey Michael, >> >> I don't think the BC break is acceptable. You argue that scalar type >> declarations are relatively new, but in fact they're already years old now. >> They're used in most PHP 7+ packages. Even if changing types might be >> discouraged, it still happens a lot. >> > > Hmm. Well, that aspect of this can be dropped. What about the rest of it?