Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122683
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------our69A0xo0oXsgRVmW3mN1sA"
Message-ID: <f4002280-bec7-459b-b65b-b261e4f52aad@rwec.co.uk>
Date: Mon, 18 Mar 2024 20:34:09 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
Content-Language: en-GB
To: internals@lists.php.net
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <CAFPFaMLZ3MeGXt5OPmAkwM-n-eZcp1gT7RQCnpXSyHxZThOn2g@mail.gmail.com>
 <CAOyH9yReYorVd1jDPyk_O73JUn1VvqEAz0Fb7mvQ6ke9k9FcZA@mail.gmail.com>
 <CAFPFaMKoH1PD_qaBPLw9pwid0NB5zyZYM7AgogYOWFhPVysEwQ@mail.gmail.com>
 <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com>
In-Reply-To: <CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------our69A0xo0oXsgRVmW3mN1sA
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18/03/2024 04:39, Alexander Pravdin wrote:
> I'm not in the context of the core team plans regarding "strict
> types". Could you share some details here? What is the current plan
> regarding it? To make strict types on by default eventually? Or
> something else?


PHP doesn't really have a defined "core team". There are contributors 
who are particularly active at a given time (sometimes, but far from 
always, because someone is paying them), contributors who are 
particularly long-standing and respected, contributors who throw 
themselves into a pet project and make it happen, and so on.

Partly as a consequence of this, it's often hard to pin down any 
long-term plan about anything, outside of what particular people would 
like to see. So Gina's opinion (it was suffixed "IMHO") that strict 
types was a mistake shouldn't be read as "we have a solid plan for what 
is going to replace strict_types which everyone is on board with".

I think a reasonable number of people do share the sentiment that having 
two separate modes was a mistake; and neither mode is actually perfect. 
It's not about "making it on by default", it's about coming up with a 
unified behaviour that makes the setting redundant.


All of which is something of a diversion from the topic at hand, which 
is this:

> How can we introduce the ability to write user code in default
> decimals and at the same time keep the old way of working as it was
> before, to not introduce any troubles into the existing code and not
> introduce performance issues? As a user, I would like to have a
> choice.



I don't think choice is really what you want: if you were designing a 
language from scratch, I doubt you would say "let's give the user a 
choice of what type 1 / 10 returns". What it's actually about is 
*backwards compatibility*: what will happen to code that expects 1/10 to 
give a float, if it suddenly starts giving a decimal.

For most cases, I think the rule can be as simple as "decimal in means 
decimal out". What's maybe not as obvious at first sight is that that 
can apply to operators as functions, and already does: 100 / 10 gives 
int(10), but 100.0 / 10  gives float(10.0), as do 100 / 10.0  and 100.0 
/ 10.0

By the same logic, decimal(1) / 10 can produce decimal(0.1) instead of 
float(0.1), and we don't need any fancy directives. Even better if we 
can introduce a shorter syntax for decimal literals, so that it becomes 
1_d / 10


Where things get more complicated is with *fixed-precision* decimals, 
which is what is generally wanted for something like money. What is the 
correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)? 
decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about 
decimal(10) / 3?

If you stick to functions / methods, this is slightly less of an issue, 
because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) 
== decimal(0.51, 2); or decimal(1.03, 2)->split(2) == [ decimal(0.52, 
2), decimal(0.51, 2) ] Example names taken directly from the brick/money 
package.

At that point, backwards compatibility is less of an issue as well: make 
the new functions convenient to use, but distinct from the existing ones.


In short, the best way of avoiding declare() directives is not to 
replace them with something else, but to choose a design where nobody 
feels the need for them.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------our69A0xo0oXsgRVmW3mN1sA
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 18/03/2024 04:39, Alexander Pravdin
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOyH9ySfZnVgpZkDbL+sP_DCmnyBaq4D=K9kHjsXXLhX-dOkcA@mail.gmail.com">
      <pre>I'm not in the context of the core team plans regarding "strict
types". Could you share some details here? What is the current plan
regarding it? To make strict types on by default eventually? Or
something else?</pre>
    </blockquote>
    <p><br>
    </p>
    <p>PHP doesn't really have a defined "core team". There are
      contributors who are particularly active at a given time
      (sometimes, but far from always, because someone is paying them),
      contributors who are particularly long-standing and respected,
      contributors who throw themselves into a pet project and make it
      happen, and so on.</p>
    <p>Partly as a consequence of this, it's often hard to pin down any
      long-term plan about anything, outside of what particular people
      would like to see. So Gina's opinion (it was suffixed "IMHO") that
      strict types was a mistake shouldn't be read as "we have a solid
      plan for what is going to replace strict_types which everyone is
      on board with". </p>
    <p>I think a reasonable number of people do share the sentiment that
      having two separate modes was a mistake; and neither mode is
      actually perfect. It's not about "making it on by default", it's
      about coming up with a unified behaviour that makes the setting
      redundant.<br>
    </p>
    <p><br>
    </p>
    <p>All of which is something of a diversion from the topic at hand,
      which is this:</p>
    <p>
      <blockquote type="cite">How can we introduce the ability to write
        user code in default<br>
        decimals and at the same time keep the old way of working as it
        was<br>
        before, to not introduce any troubles into the existing code and
        not<br>
        introduce performance issues? As a user, I would like to have a<br>
        choice.<br>
      </blockquote>
    </p>
    <p><br>
    </p>
    <p><br>
      I don't think choice is really what you want: if you were
      designing a language from scratch, I doubt you would say "let's
      give the user a choice of what type 1 / 10 returns". What it's
      actually about is *backwards compatibility*: what will happen to
      code that expects 1/10 to give a float, if it suddenly starts
      giving a decimal.</p>
    <p>For most cases, I think the rule can be as simple as "decimal in
      means decimal out". What's maybe not as obvious at first sight is
      that that can apply to operators as functions, and already does:
      100 / 10 gives int(10), but 100.0 / 10  gives float(10.0), as do
      100 / 10.0  and 100.0 / 10.0</p>
    <p>By the same logic, decimal(1) / 10 can produce decimal(0.1)
      instead of float(0.1), and we don't need any fancy directives.
      Even better if we can introduce a shorter syntax for decimal
      literals, so that it becomes 1_d / 10</p>
    <p><br>
    </p>
    <p>Where things get more complicated is with *fixed-precision*
      decimals, which is what is generally wanted for something like
      money. What is the correct result of decimal(1.03, precision: 2) /
      2 - decimal(0.515, 3)? decimal(0.51, 2)? decimal (0.52, 2)? an
      error? And what about decimal(10) / 3?</p>
    <p>If you stick to functions / methods, this is slightly less of an
      issue, because you can have decimal(1.03, 2)-&gt;dividedBy(2,
      RoundingMode::DOWN) == decimal(0.51, 2); or decimal(1.03,
      2)-&gt;split(2) == [ decimal(0.52, 2), decimal(0.51, 2) ] Example
      names taken directly from the brick/money package. </p>
    <p>At that point, backwards compatibility is less of an issue as
      well: make the new functions convenient to use, but distinct from
      the existing ones.<br>
    </p>
    <p><br>
    </p>
    <p>In short, the best way of avoiding declare() directives is not to
      replace them with something else, but to choose a design where
      nobody feels the need for them.<br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------our69A0xo0oXsgRVmW3mN1sA--