> On May 15, 2020, at 17:03, Arnold Daniels
> wrote:
>
> Hi all,
>
> I'd like to restart the discussion for the strict_opterators RFC (
> https://wiki.php.net/rfc/strict_operators).
I’m having trouble wrapping my head around this statement:
> To compare two numeric strings as numbers, they
Am 16.05.2020 um 16:56 schrieb Max Semenik :
> On Sat, May 16, 2020 at 5:20 PM Mark Randall wrote:
>
>> IMHO we need to know what is happening with editions, as I think this
>> would be an ideal candidate for that rather than another declare
>
>
> On the other hand, a declare would allow a
On Fri, 15 May 2020 at 23:03, Arnold Daniels
wrote:
> I'd like to restart the discussion for the strict_opterators RFC (
> https://wiki.php.net/rfc/strict_operators).
Hi Arnold,
That RFC is quite big, and I'm finding it hard to fit it all in my head.
I know it's annoying when people ask for
Hi all,
I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).
A number of changes have been made to the RFC since the last discussion.
These are aimed at limiting the situations where `strict_operators` will
change the behavior rather than
On Wed, Jul 10, 2019 at 11:38 PM Arnold Daniels <
arnold.adaniels...@gmail.com> wrote:
> Hi Nikita,
>
> Thanks for your feedback.
>
> I'll fix the textual errors you mentioned.
>
> * "To compare two numeric strings as numbers, they need to be cast to
> > floats." This may loose precision for
Hi,
On 10.07.19 23:37, Arnold Daniels wrote:
* I also find it somewhat odd that you can't write something like "$obj !=
null" anymore, only "$obj !== null".
To check against null, it's better to use !==. For objects (and resources)
using `!= null` is ok, but for other types, it's currently
Hi Nikita,
Thanks for your feedback.
I'll fix the textual errors you mentioned.
* "To compare two numeric strings as numbers, they need to be cast to
> floats." This may loose precision for integers. It is better to cast to
> numbers (int or float) using, with the canonical way being +$x. But I
On Tue, Jun 25, 2019 at 3:10 PM Arnold Daniels
wrote:
> Hi all,
>
> I would like to open the discussion for RFC: "Strict operators directive".
>
> This RFC proposes a new directive 'strict_operators'. When enabled,
> operators may cast operands to the expected type, but must comply to;
>
> *
On 26-06-19 23:22, Arnold Daniels wrote:
>
> I would argue the following; The explicit use of the strict_operator is
> intentional, meaning that the author consciously chose to be strict and
> does not expect some operators to still be non-strict. The issues pointed
> out, apply to all comparison
Hi Dik,
Thanks for taking the time to review this RFC.
On Wed, Jun 26, 2019 at 10:44 PM Dik Takken wrote:
> Hello,
>
> Thanks a lot for your work on this RFC, it looks like a nice way to
> allow the language to gradually move forward.
>
> As pointed out by others, the ==, ===, != and !==
On Wed, Jun 26, 2019 at 1:46 PM Benjamin Morel
wrote:
> > * in some strict mode, reserve `<`, `==` etc. for numeric comparison, and
> throw a TypeError one of the operand is not numeric;
>
> > * If we deem it worth, define a new operators for string comparison.
> (Although I’m not really sure it
Hello,
Thanks a lot for your work on this RFC, it looks like a nice way to
allow the language to gradually move forward.
As pointed out by others, the ==, ===, != and !== operators are a bit
problematic. A possible solution could be to leave them out of the RFC.
The reason to do so is that the
On Wed, Jun 26, 2019 at 12:39 PM Claude Pache
wrote:
>
>
> > Le 26 juin 2019 à 11:36, Benjamin Morel a
> écrit :
> >
> >> (...) could be the case depending on a declaration somewhere else in the
> > source code.
> >> That's the confusion Claude and I were talking about: You cannot be sure
> >
On Wed, Jun 26, 2019 at 1:18 PM Alain D D Williams
wrote:
> On Wed, Jun 26, 2019 at 12:00:18PM +0100, Rowan Collins wrote:
>
> > Perl is a notable contrast: the types of operands are deduced based on
> the
> > operator, but there are different operators to force them to different
> > types. So
>
> Given that we already have === and !==, could the strict mode simply throw
> an error for *any* use of the non-strict == and != versions?
> declare(strict_operators=1);
> var_dump( "11" == "11.0" ); # TypeError: "Cannot use non-strict equality
> operator in strict operator mode."
> var_dump(
On Wed, 26 Jun 2019 at 12:46, Benjamin Morel
wrote:
> This makes sense for "<", "<=", ">", ">=", but what about "==" and "!="?
>
> Currently, "11" == "11.0"; what would this yield under the new proposal?
>
> - leave it as is: return true in this case => contradicts the whole purpose
> of the new
> * in some strict mode, reserve `<`, `==` etc. for numeric comparison, and
throw a TypeError one of the operand is not numeric;
> * If we deem it worth, define a new operators for string comparison.
(Although I’m not really sure it is worth: we have `strcmp()` and `===` for
byte-to-byte
On Wed, Jun 26, 2019 at 12:00:18PM +0100, Rowan Collins wrote:
> Perl is a notable contrast: the types of operands are deduced based on the
> operator, but there are different operators to force them to different
> types. So `23 < 4` and `"23" < "4"` are both numeric comparisons, so return
>
On Wed, 26 Jun 2019 at 10:36, Benjamin Morel
wrote:
> Oh, I see. You mean that only replacing some of the current results with
> TypeErrors would be acceptable; returning a different value would not.
> This makes a lot of sense, but once again prevents the language from slowly
> moving towards
> Le 26 juin 2019 à 11:36, Benjamin Morel a écrit :
>
>> (...) could be the case depending on a declaration somewhere else in the
> source code.
>> That's the confusion Claude and I were talking about: You cannot be sure
> what a very simple line of code does.
>
> Oh, I see. You mean that
> (...) could be the case depending on a declaration somewhere else in the
source code.
> That's the confusion Claude and I were talking about: You cannot be sure
what a very simple line of code does.
Oh, I see. You mean that only replacing some of the current results with
TypeErrors would be
Am 26.06.2019 um 11:09 schrieb Benjamin Morel :
>
>> "120" > "99.9"; // TypeError
>> Anything else will bring confusion.
>
> Not sure about this, you can do it the JS way: if both operands are
> strings, then it behaves like strcmp():
>
> "23" > "4"; // false
> "23" > "221"; // true
>
> I'm
>"120" > "99.9"; // TypeError
> Anything else will bring confusion.
Not sure about this, you can do it the JS way: if both operands are
strings, then it behaves like strcmp():
"23" > "4"; // false
"23" > "221"; // true
I'm not saying that we should do it, but this would not be confusing to
> Le 26 juin 2019 à 08:50, Christian Schneider a écrit :
>
> Am 25.06.2019 um 15:09 schrieb Arnold Daniels :
>> This RFC proposes a new directive 'strict_operators'. When enabled,
>> operators may cast operands to the expected type, but must comply to;
>>
>> * Typecasting is not based on
Fixed the formatting. Sorry about that. :-s
I really want to have a discussion prior to creating, to make sure there is
consensus on what should be implemented. However, I will create a patch
prior to voting.
The implementation I have in mind is;
1. add a flag to `CG(active_op_array)->fn_flags`
Am 25.06.2019 um 15:09 schrieb Arnold Daniels :
> This RFC proposes a new directive 'strict_operators'. When enabled, operators
> may cast operands to the expected type, but must comply to;
>
> * Typecasting is not based on the type of the other operand
>
> * Typecasting is not based on the
Evening,
There doesn't seem to be a patch or implementation.
Aside from the proposed semantics, which I can't really read because the
document is malformed, the most important questions for me are: How is this
going to work? Can it be done without significant complexity in the
compiler or VM?
Impressive work indeed, this would be a perfect addition to strict_types
that would remove a lot of WTFs while preserving BC with older code.
Please note that the formatting of the RFC is broken after the Bitwise
Operators section.
Ben
On Tue, Jun 25, 2019 at 7:56 PM Guilliam Xavier
wrote:
> On Tue, Jun 25, 2019 at 3:09 PM Arnold Daniels
> wrote:
> >
> > Hi all,
> >
> > I would like to open the discussion for RFC: "Strict operators
> directive".
> >
> > This RFC proposes a new directive 'strict_operators'. When enabled,
>
On Tue, Jun 25, 2019 at 3:09 PM Arnold Daniels
wrote:
>
> Hi all,
>
> I would like to open the discussion for RFC: "Strict operators directive".
>
> This RFC proposes a new directive 'strict_operators'. When enabled, operators
> may cast operands to the expected type, but must comply to;
>
> *
Hi all,
I would like to open the discussion for RFC: "Strict operators directive".
This RFC proposes a new directive 'strict_operators'. When enabled, operators
may cast operands to the expected type, but must comply to;
* Typecasting is not based on the type of the other operand
*
31 matches
Mail list logo
