On Wed, Jun 24, 2020, at 8:40 AM, G. P. B. wrote:
> Greetings internals,
>
> I want to bring back the following RFC, written by Andrea Faulds, back to
> the discussion table: https://wiki.php.net/rfc/trailing_whitespace_numerics
>
> As she doesn't have time to move forward with it she allowed me
A thought -
In the event that explicit casting specifically does get tightened up,
what will become the suggested method for making a best-effort
conversion to an integer?
Personally I'm in favour of explicit casts being a bit more forgiving,
but in the event they're not, what will replace i
> Le 9 avr. 2019 à 12:47, Nikita Popov a écrit :
>
> On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
>
>> Nikita Popov wrote:
>>> I'm always a fan of making things stricter, but think that in this
>>> particular case there are some additional considerations we should keep
>> in
>>> mind.
>
> I'm somewhat split on this one.
> On the one hand, if I make an explicit cast, my intention is clear, make
> the best attempt to convert this string into a number. Trimming
> whitespace would be a natural consequence of that.
> On the other hand, I'm a stickler for consistency.
> On the balance
> On the balance of things, I would most certainly like to see leading and
> trailing whitespace render a string ineligible to be implicitly
> converted, but I'd be satisfied with (int)" 123 " converting without error.
>
Given that PHP seems to be gradually moving towards more type
strictness, wou
On 09/04/2019 14:27, Robert Hickman wrote:
Why? Wouldn't it be nice to align the behaviour of implicit and explicit
casting, so that (int) "abc" throws a TypeError?
I'm somewhat split on this one.
On the one hand, if I make an explicit cast, my intention is clear, make
the best attempt to con
> Why? Wouldn't it be nice to align the behaviour of implicit and explicit
> casting, so that (int) "abc" throws a TypeError?
>
I agree with this. It would be odd if they behaved differently.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
>
> I should probably clarify what I mean by explicit and implicit here. By
> explicit I mean anything using (int) casts or doing so internally
> (implicitly ^^) -- this *must* produce an integer in some way and does not
> have the option of rejecting the input. By implicit I mean other places
> ch
On Tue, 9 Apr 2019, Nikita Popov wrote:
> On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans wrote:
>
> > > think about the desired behavior of (int)?
> >
> > I think there should be no difference in behaviour between implicit and
> > explicit cases.
>
> So to rephrase my question: While I think th
On Tue, Apr 9, 2019 at 12:57 PM Derick Rethans wrote:
> On Tue, 9 Apr 2019, Nikita Popov wrote:
>
> > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
> >
> > > I'm kinda unsure how to go forward because of these points. I would
> like
> > > to see improved comparisons, and I would like to se
On Tue, 9 Apr 2019, Nikita Popov wrote:
> On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
>
> > I'm kinda unsure how to go forward because of these points. I would like
> > to see improved comparisons, and I would like to see the end of the
> > “non-well-formed” numeric string, and I think t
On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote:
> Nikita Popov wrote:
> > I'm always a fan of making things stricter, but think that in this
> > particular case there are some additional considerations we should keep
> in
> > mind.
> >
> > 1. What is more important to me here than strictness
Hello,
Yes and No php has an existing echo-system of extensions which could not
work
without this ini model; therefor it's fashion trend which is in my opinion
unrealistic or you
are ready to break existing infrastructures.
Enforcing the right behavior (third one) will break existing code big
ti
>
> what about exposing a strict keyword option or a php ini option?
There is a trend right now towards avoiding the language to be dependent on
php.ini options. I'm on board with this, and would personally strongly
discourage introducing such an option, and enforce one of these options for
every
Hello,
what about exposing a strict keyword option or a php ini option?
- NO - leave as it isdefault
- YES - allow trailing whitespace punks
- YES - disallow leading whitespace sane people
On Thu, Apr 4, 2019 at 1:57 AM Benjamin Morel
wrote:
> What about going
On 06/03/2019 08:58, Nikita Popov wrote:
1. What is more important to me here than strictness is consistency. Either
both " 123" and "123 " are numeric, or neither are. Making "123"
numeric is a change we can easily do, because it makes the numeric string
definition more permissive and is
What about going forward with the trailing whitespace RFC right now, but
ask to vote between 3 options?
- NO - leave as it is
- YES - allow trailing whitespace
- YES - disallow leading whitespace
And then proceeding with the string to number comparison RFC?
Ben
On Thu, 4 Apr 2019 at 01:15, Andr
Nikita Popov wrote:
I'm always a fan of making things stricter, but think that in this
particular case there are some additional considerations we should keep in
mind.
1. What is more important to me here than strictness is consistency. Either
both " 123" and "123 " are numeric, or neither a
> I was certainly not clear enough. I was thinking of basic handling of
numeric values, including arithmetic operations *and* comparison operations.
I would be interested to have a real-life use case of when the current
number comparison capabilities of PHP make more sense than those, borrowed
fr
> Le 27 mars 2019 à 16:14, Benjamin Morel a écrit :
>
>
> Sure, PHP has the huge advantage here to have a dedicated string
> concatenation operator, removing any ambiguity around the + operator. This
> does not mean that we cannot borrow their semantics for string/number
> comparison!
I wa
> Isn't this the purpose of Nikic's Saner PHP String comparison RFC?
It is, sorry I mixed the discussions here. As I said below, I think that
these RFCs would deserved to be merged.
> Because boths nikic's and Andrea's RFC go hand in hand.
> And probably if both these RFC get accepted a new "str
> Le 27 mars 2019 à 14:29, Benjamin Morel a écrit :
>
> Thinking about this a bit more, what about following JavaScript semantics? I
> find them really good in this respect:
>
Arithmetic in JavaScript cannot be used reliably (in general) without
converting your data to the proper type, beca
On Wed, 27 Mar 2019 at 14:30, Benjamin Morel
wrote:
> > It is a well-known feature that you can work with such data without
> previously converting it explicitly to some number type.
>
> I'm not requesting to change this: if you're doing string("3.5") + int(7),
> you should still get float(10.5).
> It is a well-known feature that you can work with such data without
previously converting it explicitly to some number type.
I'm not requesting to change this: if you're doing string("3.5") + int(7),
you should still get float(10.5). What I'm suggesting we change, is
comparison of numbers and de
> Le 27 mars 2019 à 00:09, Benjamin Morel a écrit :
>
> - I would also strongly suggest that 2 strings are always compared
> byte-by-byte; IMO it does (*somehow*) make sense that 42 == "42.0", but it
> DOES NOT make sense that "42" == "42.0". (...)
There are many ways to obtain numeric data
On Wed, Mar 6, 2019 at 7:41 AM Markus Fischer wrote:
> Hello,
>
> On 06.03.19 01:16, Andrea Faulds wrote:
> > https://wiki.php.net/rfc/trailing_whitespace_numerics
> >
> > I expect this should be an uncontroversial proposal, but maybe I'm
> > jinxing it there. I hope you all like it. :)
> >
> > T
Hello,
On 06.03.19 01:16, Andrea Faulds wrote:
https://wiki.php.net/rfc/trailing_whitespace_numerics
I expect this should be an uncontroversial proposal, but maybe I'm
jinxing it there. I hope you all like it. :)
Thanks to Nikita for reminding me it existed and thus motivating me to
pick it
27 matches
Mail list logo
