tiple
components rather than something specific to Curl.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 22/06/2022 05:38, Pierrick Charron wrote:
Feel free to give any feedback, concern or support :-)
This should preferably be namespaced.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 28/05/2022 03:36, Craig Francis wrote:
In this case, two of my clients are considering the cost of modifying their code (by adding a load of `?? ''` everywhere), and they would rather avoid that (time consuming, and makes their code more complicated).
Alternatively, they may wish to define
On 28/05/2022 10:53, Aaron Junker wrote:
When you have feedback to a specific point of the RFC, please use the
corresponding number used in the RFC.
To point 1, there was a time I was thinking about implementing a system
ourselves (I was working on website prototypes at the time).
That bein
On 20/05/2022 10:05, Ilija Tovilo wrote:
So unless there are concerns I will amend that in the RFC.
Erroring it out makes sense to me.
As we don't include any target version specification in PHP files, the
safest bet it so prevent the silent change from potentially leaking
through the introd
On 18/05/2022 16:23, Craig Francis wrote:
If the Session ID continued to work as the Identifier, but the client was given
the Session ID and a Random Key (could be concatenated together for the
cookie)... that means the Random Key would not be stored on the server, and
could protect the sessio
On 17/05/2022 21:36, David CARLIER wrote:
I wanted a more general but early feedback on the idea itself
https://github.com/php/php-src/pull/3759
The same question that has already been asked on github:
What is the motivation? What is it meant to achieve?
--
PHP Internals - PHP Runtime Devel
On 08/05/2022 11:48, Jordan LeDoux wrote:
This is not the case with null. If you use the unset() function on a
variable for example, it will var_dump as null *and* it will pass an
is_null() check *and* it will pass a $var === null *and* it will return
false for an isset() check. Null loses these
On 21/04/2022 22:45, Mark Randall wrote:
I have now opened voting on Undefined Property Error Promotion.
https://wiki.php.net/rfc/undefined_property_error_promotion
The vote has concluded.
The RFC has been passed with 31 votes (86%) in favour, 5 against.
--
Mark Randall
--
PHP Internals
On 25/04/2022 12:51, Christoph M. Becker wrote:
Please put your name forward here if you wish to be considered a
candidate. An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases[2].
I could potentially be interested in helping out with this, bu
On 26/04/2022 10:54, Andreas Leathley wrote:
Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true.
If we could get rid of "0" being false, that alone would be a huge
benefit for the language in the long run.
I know why it exists, but I
On 22/04/2022 21:30, Rowan Tommins wrote:
Do you not have even a little bit of hope that we could make that less
confusing, since we're breaking everyone's old code anyway?
I seem to remember we had a discussion years ago about deleting unset on
properties, but it was being used for a very po
On 22/04/2022 14:42, Rowan Tommins wrote:
As with your previous RFC, I approve of this in principle, but am
frustrated how little time has been spent considering the edge cases, such
as the ones I mentioned here: https://externals.io/message/117487#117487
Accessing an unset property, which cur
Internals,
I have now opened voting on Undefined Property Error Promotion.
https://wiki.php.net/rfc/undefined_property_error_promotion
Voting ends 2022-05-05
Summary:
This RFC seeks to prevent execution continuing if the user has accessed
an undefined property without specifying that it was
null and emits no warning
Down the line this might allow us to fix up arrays as well, but that's a
question for a different RFC.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 06/04/2022 17:34, Marco Pivetta wrote:
Perhaps worth mentioning that magic methods keep working?
Good call.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nd so removed it.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 14/03/2022 17:18, Mark Randall wrote:
I have started the vote for promoting undefined variable access to throw
an Error exception.
The vote will run for 2 weeks until March 28th 2022.
https://wiki.php.net/rfc/undefined_variable_error_promotion
The RFC has passed with 33 votes (80%) in
On 16/03/2022 09:17, Christian Schneider wrote:
Maybe we should ask ourselves the question: Why would the entire package be
blocked? Just because it is too big or maybe there *are* subtleties which have
not been properly resolved?
It's politics and the practicalities of getting things done.
On 15/03/2022 23:02, Patrick ALLAERT wrote:
I am not against the fact this warning becomes an error per se. I am just
not very fan of cherry-picking an individual kind of problem (read:
notice/warning/error/...) and changing it without a more global frame.
I think we should try to hit all of th
On 15/03/2022 19:32, Sara Golemon wrote:
What I'm hearing is that we also need an RFC for promoting 'Undefined
index...' warnings to Errors as well.
We do. If it would pass or not is another matter, it would need someone
braver than I to take it up.
I think there's some other engine straggl
I have started the vote for promoting undefined variable access to throw
an Error exception.
The vote will run for 2 weeks until March 28th 2022.
https://wiki.php.net/rfc/undefined_variable_error_promotion
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On 07/03/2022 12:56, Thomas Krüger wrote:
Or if it has nothing to do with performance, why not including
everything from PECL into PHP core, so PHP could offer out-of-the-box
more and more features for developers?
PECL packages get to maintain their own release schedule, unlike PHP
which fol
torically been overly lax with their coding standards.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 28/02/2022 01:46, Craig Francis wrote:
Personally I think `strict_types=1` is fine for my code, but I would never
want to force that style on everyone, because doing so would be fairly
hostile for a language that's popular and well known for being easy to
use/learn.
Magically coercing things
On 27/02/2022 09:12, Robert Landers wrote:
I'd also venture that this warning has caused more harm than good, in that
writing "$var['something'] ?? null" is second nature when writing new
code, even if there is practically no chance for a non-existent key.
Using null coalesce should only be
Also, this:
$name = empty($_POST['name'] ?? 'Default Name') ?: 'Default Name';
Should be:
$name = ($_POST['name'] ?? null) ?: 'Default Name')
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 26/02/2022 09:09, Robert Landers wrote:
I'd like to propose and implement an RFC that would consider dropping the
warning if and only if array access is the only test in ternary and short
ternary (?:) operations but first I'd like to start a discussion to see if
it is worth pursuing. I'd like
m, without
requiring an opt-out.
I must therefore assume you consider the use of undefined variables to
be a legitimate coding style, and that's fine if that is your position.
This RFC boils down to internals deciding, as a group, that it isn't one
we want to support in future.
On 23/02/2022 19:32, Rowan Tommins wrote
I think that wording change should be part of the proposed change in the
RFC. Otherwise, a lot of people simply won't know the decision to remove
it has been made and will be surprised when 9.0 comes around.
It is already part of the RFC within the "pro
m actually doing it.
It may be that in 8.2 if this RFC passes that message will change to
include "This will throw an error in PHP 9", but giving multiple
messages for it is not beneficial IMO.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
unaffected.
If there's am existing formal definition someone wishes to contribute,
I'd be happy to update it.
One thing maybe worth mentioning is that while most operators such as
++, +=, .= etc will be covered by this change, $undefined[] = 1; will
not be.
Mark Randall
--
On 22/02/2022 09:15, Nicolas Grekas wrote:
I very much call for an implementation to be provided before starting any
vote on the topic btw.
The RFC states on its first line that accessing an undefined variable
emits an E_WARNING. If it does not currently emit an E_WARNING then it
is out of scop
On 21/02/2022 10:29, Nicolas BADIA wrote:
and I don’t find the code more readable. Here are some examples of changes:
The example changes you provide are what many people here would
recommend as good practice to improve the context and safety your code
provides.
Anyone looking at that code
a special case that means it
will be affected by this proposal.
It is intended to be affected by this proposal.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s at all is because an undefined variable read
falls back to null, and the increment operator is hardcoded to treat
null++ as 1.
That's why if you do this:
$x = $foo++;
var_dump($x);
You get:
Warning: Undefined variable $foo in on line 3
NULL
Mark Randall
--
PHP Internals - PHP Run
other error promotions forward, potentially in
collaboration with other developers, but as this is the biggest change,
and the most likely to attract a large number of comments, I thought it
deserving of a standalone RFC.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To
or unable to do that, you may instead wish to stay
on an older version that hax more lax behaviour, and purchase LTS from
the likes of Zend.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/02/2022 13:49, Robin Chalas wrote:
What do you think?
It sounds like you need to wrap get_debug_type rather than introduce a
magic method into core to account for framework oddities.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
On 07/02/2022 15:34, Craig Francis wrote:
So are you suggesting that all the frameworks should change their default
to an empty string? or every single project should update every use of
these input functions to always override this default, or cast the received
value to always be a string? all t
mment, any framework worth its salt
will also have the option to provide a default value other than null
when the value is not provided.
It is the responsibility of the user to make use of this functionality
to provide the correct type for what the soon-to-be-called function is
expecting.
M
ould be progressing.
It sucks that it was ever allowed in the first place.
PHP has a long history of making descisions to try to make things 'just
work', and if history teaches us anything, its that we inevitably come
to regret these descisions down the line.
Mark Randall
--
PHP Inter
On 29/01/2022 16:33, Christian Schneider wrote:
If a static analyzer manages to catch it at development time then that is a lot
better.
Of course it's better, but you wouldn't argue that a car doesn't need
airbags because you've tested that the breaks work.
Defense in depth.
Our ecosystem
On 27/01/2022 22:09, Larry Garfield wrote:
I am not sure what additional value is gained by making the scream even louder.
For us to make something an exception at engine level, is to stop
execution on the grounds that the engine no longer considers it safe to
continue.
That might be becau
, too lax in this regard.
We should be aiming to provide a reasonably safe experience out the box.
That you're manually patching PHP to change official behaviour (which
was passed by RFC) puts your individual use case well outside of what
should be considered when voting.
Mark Randa
PHPs lifetime, maybe even in PHP 9, but I am not proposing
it with this batch of updates.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
gs shake out, we can decide what route to take
with regards to bringing RFCs to vote.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
https://wiki.php.net/redefine_constants_exception_strawpoll
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/12/2021 05:22, André Hänsel wrote:
This is very useful because I can add an optional parameter to a function
and prevent users of my function from using the parameter in a positional
way. This way I don't have to make a compatibility promise to never change
the position of this parameter.
this RFC focuses heavily on array_columns, including all of the
examples and the PR, I would encourage the author to consider an RFC
specifically for array_column_group.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 04/12/2021 14:21, Marco Pivetta wrote:
Gonna vote `no` on this: please design new/dedicated functions, rather than
expanding optional parameters.
I would vote no for the same reason.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
s that old code will need to be modified to
be compatible with those measures.
To do otherwise would be entirely unethical.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 23/07/2021 10:58, Nicolas Grekas wrote:
Hi everyone,
I wrote everything down about the reasons why here:
https://wiki.php.net/rfc/nullable_intersection_types
IMO we should require brackets and forbid not using them when combining
unions and intersections.
These types are already going to
On 06/06/2021 14:00, Ben Morss via internals wrote:
Thank you for these comments!
Perhaps it would make sense to, at some point, create a followup proposal
to namespace the entire gd extension - so that all gd functions would be in
the namespace? I'd leave it to others to determine whether this
to a variable of type false will throw a
deprecation error"
You might want to clarify this language, throwing an error is understood
to have a specific meaning in PHP, and it's not what it's doing here.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
e example by any
stretch, but but I do get the feeling that, as we can future proof it
for effectively zero cost, we should.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
what would traditionally be a by-ref, repeating
the previous lookup with FETCH_DIM_W?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 15/05/2021 01:00, Larry Garfield wrote:
I can't speak for the others, but I could tolerate making "more than one extra ? beyond the end of the parameter list is an error", potentially, as at that point they're redundant. But if a function has, say, 4 params, then fourParams(1, 3, ?) is a conve
On 14/05/2021 22:48, Aaron Piotrowski wrote:
I think it’s reasonable to allow passing more arguments to a partial since
user-defined functions and closures allow this without error.
But only userland functions, a relic from when func_get_args was the
only way to handle varaible numbers of arg
}
Equally it matches the syntax for unpacking into arguments:
$a = foo($a, ...$b);
Passing more arguments than the partial defines would result in an
argument count error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 09/05/2021 09:05, Stanislav Malyshev wrote:
I don't see how we could "just move" if all our bug handling would be
wired into Github. I can easily see how we could move a repo to any
provider that supports git - git is a generic platform, Github is just a
frontend. But there's no alternative
On 08/04/2021 19:38, Stanislav Malyshev wrote:
I think it's just because nobody has focused attention to it. As you
see, once it was focused, it has happened.
This is usually referred to as shutting the stable door after the horse
has bolted.
--
PHP Internals - PHP Runtime Development Maili
On 15/03/2021 17:41, Mark Randall wrote:
I would like to propose the addition of a new mechanism of autoloading
classes - a classmap that will be consulted prior to checking the
spl_autoload_register'd callbacks.
https://wiki.php.net/rfc/autoload_classmap
Does anyone else have any
On 27/03/2021 16:52, Abdul Haq Sheikh wrote:
- On Index.php, php will automatically include 'vendor/autoload.php'
because the vendor directory exists.
- On Test.php, php will automatically include 'vendor/autoload.php'
because the vendor directory exists.
- On Classes/test2.php, since file is i
On 25/03/2021 13:54, Olle Härstedt wrote:
JS does not support "definitely local". No language does, AFAIK.
Unless you count value types.
We were both refering to block-level variables, which most languages do.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
On 25/03/2021 09:28, Rowan Tommins wrote:
That's not quite what I meant. I meant that you can't say "capture by
default, but this variable is definitely local".
I think if there's one argument against, this would be it, but IMHO it
is a weakness in PHP as a whole.
The solution would be addin
} instead.
For me auto capture is a solid +1.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
mance only).
>>
I appreciate this is a small amount. If internals feels the additional
code is not worth it for such a small gain, I have no issue at all with
the RFC being rejected.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
extremely common
operation is worth the few dozen lines of code required.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ote that only the array key is lowercase, the value,
the path name, IS case sensitive.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 15/03/2021 22:18, Levi Morrison via internals wrote:
Like any other case insensitive symbol PHP works with that comes from
userland, I would lower it in the engine's side of things. I would not
push the lowercase requirement on the API.
That was the first design, however it required re-creat
On 15/03/2021 17:59, Levi Morrison via internals wrote:
IMO, these should be the defined case of the class, or we should be
insensitive about it. It's one thing that our symbols are case
insensitive; it is wholly another to _require_ it for this feature by
requiring lowercase names. I assume ther
Hi Internals,
I would like to propose the addition of a new mechanism of autoloading
classes - a classmap that will be consulted prior to checking the
spl_autoload_register'd callbacks.
https://wiki.php.net/rfc/autoload_classmap
Mark Randall
marand...@php.net
--
PHP Internals - PHP Ru
On 18/02/2021 03:37, Mark Randall wrote:
Long ago, PHP had a similar feature called Magic Quotes.
My apologies, I had only that top paragraph visible in my preview and
responded to entirely the wrong part of your post :-(
--
PHP Internals - PHP Runtime Development Mailing List
To
Quotes.
It is now universally considered to be among the worst and most damaging
features that PHP ever introduced.
There is no apetite to reintroduce such a thing.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ave a significantly bigger
and more beneficial impact on userland.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
together.
If SPL\ is to exist (and personally I think SPL is so cancerous, it
shouldn't) then IMO it must absolutely be SPL\iterators.
Without that all we've done is swap one problem for another.
The idea of putting data structures next to generic iterator helpers is,
quite fran
On 08/02/2021 15:14, Kalle Sommer Nielsen wrote:
Den man. 8. feb. 2021 kl. 17.08 skrev Levi Morrison via internals
:
- I do not like the chosen namespace. This is not as important as the
previous point, but still factored into my decision as we are still
very early in choosing namespaces for int
candidates for
\PHP\SubNS rather than \Ext\SubNS
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
tch combined with a match.
It avoids the need for two methods, just provide the one that throws and
use shorthand to assign a null if it throws.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 06/01/2021 14:57, Nikita Popov wrote:
Once you introduce an
additional meaningful namespace in the form of SPL\iterable\any, you are
better off either dropping the SPL part and arriving at iterable\any, or
replacing SPL with something more sensible and arriving at PHP\iterable\any.
PHP\Mod
On 19/12/2020 20:24, tyson andre wrote:
Hi internals,
I've created a straw poll for the naming pattern to use for `*any()` and
`*all()` on iterables.
https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
These functions make sense. However I think we need to give renewed
consideration to:
On 11/11/2020 20:20, David Rodrigues wrote:
If yes, what is the reason for requiring it? Why it can't be the default
behavior (or maybe, the unique behavior).
There was some discussion around the idea of adding language editions to
PHP for 8.0, however the pandemic resulted in to the in-person
On 01/09/2020 16:05, Levi Morrison via internals wrote:
Anyway, the key point I'm making is that I think a larger RFC has a
better shot of passing if we want to namespace it.
Try as we might 4 of us working together couldn't get namespaces
accepted. I got the feeling that there seems to be an
ll the only breakage would be if people were using external
code to do pre-processor like operations such as using #start and #end
as quasi-tags.
Ideally, if we pass #[ ] we would deprecate # in the same version and
put it on the fast-track to removal, but that would require an
additional
,
#[Inject] Bar $bar,
string $value
) {
...
}
}
$container->factories(Foo::class)("value");
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
like those examples, we shouldn't make accomodation for them or
anything like them in future.
Adopting such extensions is a matter for a future RFC, and not for
preemptively throwing a spanner in the works.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
tely different might happen.
What is clear is we've got to support Attributes for 20, 30 years, and
we should leave the door open for easier and cleaner syntax additions if
there's no compelling reason not to.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing Lis
On 26/07/2020 17:24, Larry Garfield wrote:
The vote on the PHP namespace policy is now open:
https://wiki.php.net/rfc/php_namespace_policy
Thanks to Larry for putting in a lot of effort with this RFC.
I would like to think this RFC provides a solution to a legitimate
long-term problem.
1. I
protected Attr) but at which point why not
just use a mechanism that supports it out of the box?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 23/07/2020 08:02, Côme Chilliet wrote:
To be clear, is there anyone who voted for @@ and changed his mind based on new
information?
Please see the initial discussion here:
https://externals.io/message/110568#111038
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
mmit ourselves to 20+ years of supporting a syntax that we
already have strong reservations about before it's even out the door.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t; the result could turn out differently. The
only way to know is to take another vote.
Yes we do - it was a ranked choice vote where voters selected their
first, second and third preferences.
If @@ is eliminated, the second choice of all those who voted for it as
their first choice is alrea
there are perfectly good
alternatives?
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 20/07/2020 16:58, Michael Wallner wrote:
Distilled down, I just cannot see any huge benefit out of a (or two) root
namespace(s). As a project we rightfully own the root namespace, and
putting everything beneath PHP just doesn't make any sense to me.
You cannot just "own" the root namespace i
On 17/07/2020 09:23, Lester Caine wrote:
So does that also apply to \Ext? Currently the selection of extensions
is flexible and most distributions allow the easy repackaging of just
what is available. Creating a 'core' set off extensions under \PHP is
essentially saying 'you will make these ava
On 17/07/2020 04:49, Levi Morrison via internals wrote:
I don't care to debate it. I will just vote no.
Fair enough, however the point of the internals mailing list and
discussion period is to debate the RFCs :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
depending on its location. The
purpose of that one level is to avoid extensions trampling into multiple
userspace naming areas.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 16/07/2020 15:43, Nikita Popov wrote
I haven't backported any deprecation warnings to 7.4. Adding deprecations
to released versions is a hard no-go.
My apologies.
I'd got my wires crossed with seeing
https://github.com/php/php-src/pull/3917 appear on the PRs.
--
PHP Internals - PHP Runti
some
changes coming in 8.0?
So it's not really impossible... it just takes the will to do it.
We can keep making small tweeks trying to make it better, or we can just
do the "proper" thing, reject everything except exclusively
properly-formatted numbers, and put the issue
1 - 100 of 237 matches
Mail list logo
