I have two suggestions, assuming you proceed roughly as outlined in your
original post.
1. Start with /community
A new community website [4], it can be a place for people to ask
questions and discuss php in general - no one uses IRC anymore.
and use it to build and coordinate the dev team fo
Hi George,
Iiuc, the problem you're trying to solve is that PHP offers too many
ways to do the same thing and if there were fewer then PHP code would be
easier to write, read and maintain.
Differences in code that make no difference to the compiler are
differences in style.
The conventiona
On 2 Dec 2018, at 17:50, Christoph M. Becker wrote:
> Regarding other prominent features, I think the “Flexible Heredoc and
> Nowdoc Syntaxes”[2] and the “PCRE2 migration”[3] should certainly be
> mentioned. Also the MBString improvements[4], as well as the
> deprecations[5], and also the file re
Hi Sammy,
On 22 Oct 2018, at 9:46, Sammy Kaye Powers wrote:
What makes the function obsolete? The addition of the `random_bytes()`
Yes.
What makes the function obsolete? The addition of the `random_bytes()`
CSPRNG (which uses the kernel's CSPRNG) doesn't invalidate OpenSSL's
CSPRNG.
Accor
On 19 Oct 2018, at 16:46, Sammy Kaye Powers wrote:
I'd like to start a discussion on the "Improve
openssl_random_pseudo_bytes()" RFC:
https://wiki.php.net/rfc/improve-openssl-random-pseudo-bytes
TL;DR:
CSPRNG implementations should always fail closed so this change would
make `openssl_random_p
On 8 Sep 2017, at 17:41, Andrea Faulds wrote:
Hi everyone!
Here's an RFC for a small, simple, self-contained feature with no
backwards-compatibility breaks and which in fact doesn't even touch
the language's syntax (it's 50%+1 eligible!) but which could make PHP
a bit more expressive and con
On 8 Sep 2017, at 8:31, Solar Designer wrote:
On Fri, Sep 08, 2017 at 07:56:23AM -0400, Tom Worster wrote:
From: Nikita Popov
Sorry for the long delay. I've just applied
https://github.com/php/php-src/commit/fd07302024bc47082b13b32217147fd39d1e9e61
to the 7.2 branch.
Davey, Joe, do we
From: Nikita Popov
Sorry for the long delay. I've just applied
https://github.com/php/php-src/commit/fd07302024bc47082b13b32217147fd39d1e9e61
to the 7.2 branch.
Davey, Joe, do we want to take action here for 7.1? It's a pretty
severe
bias, but fixing it is going to change seed sequences. I t
On 2/7/17 3:22 PM, Scott Arciszewski wrote:
One such real-world use case: Defuse v1 used HKDF without a salt.
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L157-L170
https://github.com/defuse/php-encryption/blob/b87737b2eec06b13f025cabea847338f
On 3 Feb 2017, at 18:56, internals-digest-h...@lists.php.net wrote:
HKDF w/o salt is OK, but with salt, it's much stronger than w/o it.
That's not correct.
The salt defends against certain attacks on predictable input key
material, i.e. weak passwords. But HKDF should not normally be used fo
On 1 Feb 2017, at 22:47, Yasuo Ohgaki wrote:
Posting RFC draft before discussion
https://wiki.php.net/rfc/improve_predictable_prng_random
This RFC includes results of recent PRNG related discussions.
I would like to keep it simple, but basic object feature will be
implemented.
Methods could r
On 2 Feb 2017, at 8:24, Christoph M. Becker wrote:
On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
Although users must never do this, but there are codes that generate
random
password/access key by mt_rand().
There is also code that stores clear text passwords. How would you
prevent that?
IMH
On 1/28/17 4:32 PM, Yasuo Ohgaki wrote:
Could you give some examples?
I'm not sure what kind of IoT devices/OS that support PHP do not have
CSPRNG.
I'm sorry, my reply ended up with subject "Re: internals Digest 27 Jan
2017 10:58:15 - Issue 4425". My fault. I'll copy it here...
There a
On 27 Jan 2017, at 5:58, internals-digest-h...@lists.php.net wrote:
One would like to think so but low entropy environments exist. The
problem
may even be getting more widespread as embedded systems become more
widespread.
Could you tell us which platforms could have problem with CSPRNG
u
Hi Andrey,
Is there a draft of end-user docs for the PHP function?
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I saw "**PHP 7.1.0 Released**" on php.net
yay! props to contributors. and thank you.
tom
On 9/22/16 3:46 AM, Rowan Collins wrote:
I think I'm right in saying that the power of the attack comes in the fact that
the total time doesn't scale linearly but exponentially.
quadratic is what i read in the previous thread, iirc. even so, it's
still a useful gain.
That doesn't exactly
On 9/21/16 8:37 AM, Rowan Collins wrote:
On 21 September 2016 13:02:20 BST, Glenn Eggleton wrote:
What if we had some sort of configuration limit on collision length?
Previous discussions have come to the conclusion that the difference between
normal collision frequency and sufficient for a
On 9/20/16 10:25 PM, Stanislav Malyshev wrote:
Note that to avoid problems with opcache we can only randomize on
initial boot (even then synchronizing among different processes sharing
opcache may be challenging). That means that the process would be
running for extended time (at least days, in t
On 9/15/16 2:48 PM, Scott Arciszewski wrote:
Would the Internals team be open to discussing mitigating HashDoS in a
future version of PHP? i.e. everywhere, even for json_decode() and friends,
by fixing the problem rather than capping the maximum number of input
parameters and hoping it's good en
On 9/16/16 1:59 AM, Thomas Hruska wrote:
If anyone wants a VERY rough estimate of relative performance
degradation as a result of switching to SipHash, here's a somewhat naive
C++ implementation of a similar data structure to that found in PHP:
https://github.com/cubiclesoft/cross-platform-cpp
On 9/9/16 6:12 AM, Nikita Popov wrote:
The problem with "fixing" this function to be cryptographically
unpredictable (rather than just unique, for a limited definition of unique)
is that it will necessarily change the size of the output, on which there
may be assumptions. A 128 bit random value
On 9/9/16 7:48 AM, Yasuo Ohgaki wrote:
Some of us feel returning almost random value from uniqid() is
overkill. This is reasonable.
How would it be overkill if uniqid() used, say, php_random_bytes()?
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
On 9/9/16 7:18 AM, Arvids Godjuks wrote:
2016-09-09 13:37 GMT+03:00 Niklas Keller :
Most people think getting true random is a overkill and implement things
non-secure.
Most? Idk. But there certainly are many programmers that still believe
the **myth** that one should be conservative of the
On 9/9/16 4:36 AM, Arvids Godjuks wrote:
It's also useful in other cases, where using a full blown true random
source is just overkill.
Users should not hesitate to use random_bytes() or php_random_bytes() or
any of the functions that use them.
For example, my recent usage was to use the
On 9/2/16 3:32 PM, Davey Shafik wrote:
Hi internals,
I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
in 8.0),
Yes!
It's good for the software (and its users) if it is maintained and
contributed to using _currently_prevailing_conventions_ in f/oss.
as well as ad
On 8/16/16 10:51 AM, Lester Caine wrote:
On 16/08/16 13:08, Tom Worster wrote:
The default 128 bits Session ID is large enough to ignore collisions
https://wiki.php.net/rfc/session-create-id#discussions
It describes for an application, but PHP is a platform.
There are millions PHP apps or more
On 8/17/16, 3:48 PM, "Charles R. Portwood II"
wrote:
>Hi everyone,
>
>I've spent the last week and a half playing around with various cost
>factors on different virtual machines and hardware (including compiling
>this down for armv6 and testing on a Pi Zero), and looking over the spec
>a bit more
On 8/15/16, 5:39 PM, "Yasuo Ohgaki" wrote:
>On Tue, Aug 16, 2016 at 6:03 AM, Yasuo Ohgaki wrote:
>> On Tue, Aug 16, 2016 at 5:21 AM, Tom Worster wrote:
>>> On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
>>>
>>>> "Now assume a 128 bit se
On 8/14/16 4:13 PM, Yasuo Ohgaki wrote:
"Now assume a 128 bit session identifier that provides 64 bits of
entropy.
What exactly does this mean?
If it means that an attacker knows how to eliminate 2^128 - 2^64
impossible SID values from a search then that SID generation is
insecure, dangerou
On 8/13/16 9:02 PM, Yasuo Ohgaki wrote:
Hi Tom,
On Sun, Aug 14, 2016 at 12:35 AM, Tom Worster wrote:
Rather than argue the details of randomness, I have more basic comments.
1. If an app needs to access session values, it can and should do this
without indirection through the PHP session ID
Hi Lauri,
Do you have a PR against php-src on github? It's easier to read and comment.
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 8/14/16, 5:45 AM, "Lauri Kenttä" wrote:
>On 2016-08-13 18:53, Tom Worster wrote:
>> On 8/12/16 2:48 PM, Lauri Kenttä wrote:
>>> On 2016-08-12 21:40, Tom Worster wrote:
>>>> mt_srand() will work. But what would be in the array? Integers from
>>
On 8/12/16 2:48 PM, Lauri Kenttä wrote:
On 2016-08-12 21:40, Tom Worster wrote:
mt_srand() will work. But what would be in the array? Integers from
which the upper 32 bits, if they exist, are discarded?
mt19937ar.c contains init_by_array.
Compability with that would probably be a good goal
On 8/10/16 5:14 AM, Yasuo Ohgaki wrote:
Hi all,
This is RFC for adding session_create_id() function.
Session ID string uses special binary to string conversion. Users
should write lengthy and slow code to have the same session ID string
as session module does. It also validates and makes sure g
Hi Yasu,
On 8/12/16, 4:38 PM, "Yasuo Ohgaki" wrote:
>Base 64 adds padding for extra bytes. The Padding char is "=" and it's
>illegal char as SID. Therefore trims is mandatory.
substr(base64_encode(random_bytes($n)), 0, $n). There is no "=" in the
value for any $n.
>Don't you think it's nice t
On 8/11/16 10:13 AM, Lauri Kenttä wrote:
Hello,
Any thoughts about supporting a longer seed array for mt_srand? Does
anyone really need it? Should it be in mt_srand or mt_srand_array?
See: https://bugs.php.net/bug.php?id=32145
The second question is controversial.
People have asserted that n
On 8/11/16 6:58 PM, Yasuo Ohgaki wrote:
Hi Leigh,
On Fri, Aug 12, 2016 at 3:25 AM, Leigh wrote:
On Wed, 10 Aug 2016 at 10:15 Yasuo Ohgaki wrote:
Hi all,
This is RFC for adding session_create_id() function.
Session ID string uses special binary to string conversion. Users
should write leng
On 8/8/16 5:36 PM, Leigh wrote:
Hi all,
There has been an unforeseen break with rand() when the minimum value is
greater than the maximum.
Prior to 7.1 rand() would happily accept backwards parameters and return a
value, however in the 7.1 branch it now emits a warning and returns false.
I've
On 8/6/16, 1:55 PM, "Charles R. Portwood II"
wrote:
>Typically a run time of of under 50 ms is the target goal. Argon2 can be
>tweaked to use a specific amount of memory, time, or CPU cores. Trying to
>find good default cost factors is problematic since all 3 of those
>factors are variable on any
On 8/5/16, 2:20 PM, "Charles R. Portwood II"
wrote:
>It breaks the API in the interim between this RFC and a potential future
>one. The $options parameter for both password_hash and
>password_needs_rehash is optional. Making it required for one algorithm
>but not another changes the API's for bot
On 8/5/16, 12:36 PM, "Charles R. Portwood II"
wrote:
>I understand what you're saying. Ryan said it a bit more clearly than I
>did, making the options required causes backwards-incompatible changes to
>the password_hash API. That's my real reservation behind not providing
>defaults.
>
>A separat
On 8/5/16, 11:08 AM, "Ryan Pallas" wrote:
>Please keep it so that defaults will work, but $options is available for
>tuning as that's how the feature currently works.
My suggestion doesn't affect that. I agree that password_hash($password,
PASSWORD_DEFAULT) should always "just work".
Instead, I
On 8/5/16, 10:49 AM, "Charles R. Portwood II"
wrote:
>I think for clarity, PASSWORD_ARGON2I would be sufficient. What are your
>thoughts?
Looks good.
>The rationale for providing defaults is to ensure the password_*
>functions remain easy to use.
I understand. I was actually suggesting that w
On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
The RFC is available at: https://wiki.php.net/rfc/argon2_password_hash.
Hi Charles,
Thanks for doing this. I'm glad Argon2 is coming to PHP.
You can have a longer voting period if you like, which I think would be
a good idea.
I think it's con
On 7/7/16 6:39 AM, Leigh wrote:
As the discussion thread has been quiet for a while, moving this RFC to voting.
https://wiki.php.net/rfc/rng_fixes
https://github.com/php/php-src/pull/1986
Nice work.
The discussion persuaded me (Nikita mostly) that aliasing rand() to
mt_rand() is sensible. A
On 7/5/16 11:37 AM, Christoph Becker wrote:
On 05.07.2016 at 16:32, Leigh wrote:
On 5 July 2016 at 04:02, Pierre Joye wrote:
We can argue about the provided pnrng being CS but it is not php's job to
decide.
I think we need to drop the concerns about exposing "RNG state".
A reminder of what
On 6/23/16 12:56 PM, Stanislav Malyshev wrote:
Hi!
I would prefer something like random_fast_int() == mt_rand() == rand(),
with clear documentation on when to use random_fast_int() instead of
random_int(), and a note on the others that "since 7.2, mt_rand() is an
alias for random_fast_int()" et
On 6/22/16, 5:19 PM, "Nikita Popov" wrote:
>I haven't been following this thread, just jumping in to comment on this
>point. My suggestion to deprecate rand() was motivated by the fact that
>rand() produces extremely low quality random numbers on Windows, while at
>the same time having the name p
On 6/21/16 3:29 PM, Fleshgrinder wrote:
My favorite:
The PHP approach seems to be that any crazy behavior is acceptable as
long as it's documented.
People love raggin' on PHP.
It's a virulent meme. It propagates so well in our coder culture because
it's easy, it's just provocative enough t
On 6/21/16 3:23 PM, Lester Caine wrote:
Can someone explain why I should need 'crypto safe' random numbers when
ALL *I* use rand for is to give a random order to content items on the
page.
I cannot.
Something more in sync with the shuffle and array_rand without the
need to recode to actuall
On 6/21/16 2:32 PM, Stanislav Malyshev wrote:
What is for you "obviously faulty stuff" for literally thousands of
people is "code that works". I appreciate that there's a number of new
hip randomness tests that mt_rand may not satisfy
As far as I can tell
https://gist.github.com/tom--/a121750
On 6/21/16, 1:43 PM, "Fleshgrinder" wrote:
>Yes, let's ask the users! But we don't do that, we just discuss it here.
>Howe could we create such a poll that reaches many people? Maybe Reddit?
Perhaps you misunderstand what I intended by leaving the choice to users.
If we add a new RNG and keep th
On 6/19/16, 12:59 PM, "Fleshgrinder" wrote:
>This matches Tom Worster's analysis of mt: it's just crap. :P
Actually I satisfied myself that both MT19937 and PHP's mt_rand() produce
good quality random variates and I posted the evidence behind the belief.
I don't think being slow and inefficient
Hi Leigh,
I need to change stance wrt MT.
On 6/16/16, 2:31 PM, "Leigh" wrote:
>I get your point, but most people probably use mt_rand() because "it's
>better than rand". mt_rand is also incredibly slow and has a huge state
>when compared to modern algorithms. I should probably note the
>perfor
On 6/15/16 9:04 AM, Jordi Boggiano wrote:
Just a thought here, if the goal is to provide a better interface,
Hi Jordi,
Iiuc, Leigh's goal, which I support, is to fix known bugs. It is not to
provide a better interface.
I already suggested that if people want new RNGs or a new API then we
On 6/15/16 6:33 AM, Pierre Joye wrote:
> * Alternatively, fixing the current mt_rand() implementation to make it
> standard
That sounds more reasonable. An option (please no ini as it is a
programatic flow feature, not a php configuration problem) to keep the
old behavior for BC. Having to add a
On 6/14/16 3:12 PM, Fleshgrinder wrote:
Call me ignorant but is this required in typical web applications?
PHP is used for various things, not just web apps. I use it for various
other things because its the language in which I am most fluent.
And the requirements of *typical* apps using PH
On 6/14/16 1:45 PM, Fleshgrinder wrote:
Why do we need so many functions to get a random int anyways if we now
have random_int()?
For backwards compatibility. There are programs that use these and
little to gain from breaking them.
Tom
--
PHP Internals - PHP Runtime Development Mailing Li
On 6/14/16 12:46 PM, Leigh wrote:
The RFC can be found here: https://wiki.php.net/rfc/rng_fixes
Hi Leigh,
Thanks for putting this together. I am strongly pro on two points and
moderately contra on the other two. I'd prefer separated votes, even
though I don't have a vote. I numbered the 4 b
On 6/5/16 4:31 AM, Scott Arciszewski wrote:
> - memzero, memcmp, hex2bin
>
> I am not totally convinced that memzero and maybe memcmp names are
> good nor they should be there. Both would be very useful as operator
> on variables. Given the simplicity of the implementations, it could be
> very us
On 5/26/16, 12:48 PM, "Fleshgrinder" wrote:
>>
>> Under another 5th option, the problem you state does not arise. Disallow
>> "public int $x;". Under this option you may declare $x with type int and
>> an initial value or you may declare $x without type but you may not
>> declare $x with type (n
set($a->z)); // false
>var_dump($a->z); // Fatal error, uninitialized...
>var_dump($a->u); // Fatal error, uninitialized...
>var_dump($a->v); // Fatal error, uninitialized...
>var_dump($a->w); // Fatal error, uninitialized...
>
>var_dump(isset($a->x)); // fal
On 5/26/16, 12:30 PM, "Fleshgrinder" wrote:
>The problem is a completely different one, how should the following code
>behave?
>
> class A {
>
>public int $x;
>
> }
>
> (new A)->x;
>
>The property has no value assigned but it is being accessed. The current
>PHP behavior is to simply initia
On 5/26/16, 11:02 AM, "James Gilliland" wrote:
>Sarcasm aside, I still can't figure out how fundamentally changing how
>people interact with uninitialized properties like this improves
>developer experience. Can someone explain a case where this is better and
>catches a bug or something? Since th
On 5/25/16 5:52 PM, Thomas Bley wrote:
I'm not seeing a problem here:
class A {
public int $x;
public ?int $y = null;
public int $z = 42;
public ?int $u;
public ?datetime $v;
public datetime $w;
}
$a = new A;
var_dump($a->x); // 0 + notice
var_dump($a->y); // null
var_dump($a->z); /
On 5/25/16 6:03 PM, Stanislav Malyshev wrote:
Hi!
> Andrea already said that we would not use it for untyped properties,
> hence, no BC.
Again, it's not that simple. Properties are not local. That means any
code that can deal with a class that may have typed properties (which
may be library cl
On 5/25/16 9:03 AM, Nikita Popov wrote:
On Wed, May 25, 2016 at 10:30 AM, Joe Watkins wrote:
Morning Dmitry,
> I made this check(s) to be invariant. You may like to do this
differently...
I think this is what everyone expects, isn't it ?
I did omit to mention that part ...
> RF
On 5/20/16 2:05 AM, Joe Watkins wrote:
Morning internals,
Since we have our answer on nullable types, typed properties can now go
to vote.
https://wiki.php.net/rfc/typed-properties#vote
Note that, support for nullability as RFC'd will be merged when the
implementation for nullable_
On 5/7/16, 1:19 PM, "Nikita Popov" wrote:
>This RFC has one primary vote and one secondary vote. The primary vote
>determines whether we want to add nullable types to our type system. The
>secondary vote decides how precisely this will happen, in this instance
>deciding whether nullable types wil
On 5/6/16 3:41 PM, Levi Morrison wrote:
The [RFC for Nullable Types][1] is going to go into the voting phase
soon. There have been a few changes to the RFC in the meantime:
- More example for documentation's sake
- The vote is now split into two parts: one for nullable parameter
types and
On 4/28/16 4:41 PM, Björn Larsson wrote:
Can't resist jumping into this discussion, but when I first read
both RFC's, I found them quite complementary.
In one sense, I agree. But when it comes to the question: let's vote on
the options to decide what, if anything, happens to PHP, they are
op
/php-src/pull/1045
>
>I would be also glad if your "Nullable Types" RFC was accepted now, but I
>don't trust in your intention to support it.
>
>
>From: morrison.l...@gmail.com on behalf of Levi
>Morrison
>Sent: Thursday
On 4/26/16 12:10 PM, Sara Golemon wrote:
On Tue, Apr 26, 2016 at 2:06 AM, Yasuo Ohgaki wrote:
Things might have been changed, but as you've mentioned encoding
detection is unstable and ICU is poor compared to mbstring's detection
at least for Japanese encodings.
For me, the difference is that
On 4/26/16 10:58 AM, Bob Weinand wrote:
Yeah, I'd like to not allow ?Foo in any case if union types pass.
If they fail, ?Foo is fine for me.
I am persuaded that using the HHVM grammar is best. I personally don't
like but it makes sense.
If the Union RFC would propose only the | grammar and b
On 4/26/16 12:21 PM, Christoph Becker wrote:
On 26.04.2016 at 16:24, Dmitry Stogov wrote:
At first, I'm glad this implementation is ready.
At least it's possible to analyze its profs and cons.
I'm also sure that both RFCs have their opponents and advocates.
Now, I just like to make the final v
Hi Thomas,
Sorry for the delay. I was traveling last week.
By convention `return;` in PHP is an early return for a function that
returns nothing at all. I think it can be confusing when reading a
function to look at a `return;` line and have to remember to look
elsewhere to discover what that mea
On 4/19/16 7:21 PM, Rick Widmer wrote:
Are too many of these incompatible shiny things, too fast, the main
reason so many PHP users are on older versions?
IMHO, yes.
This would mean, by an large, that people had tried a more recent
version of PHP and found that their code was incompatible. I
On 4/18/16 4:34 AM, Tony Marston wrote:
I repeat, where was the insult in the post in question? What exactly
were the insulting words?
I chose just one example:
> Those who cannot write effective software without these "clever"
> additions to the language are doing nothing but announcing to
On 4/18/16 2:24 PM, Stanislav Malyshev wrote:
I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entra
On 4/16/16 5:04 AM, Tony Marston wrote:
"Marco Pivetta" wrote in message
news:CADyq6sJfPYgQvhQt=uvcbqkoojjoupcz1sufzwxc+55hl0p...@mail.gmail.com...
Tony, that sounds really like "real programmers use `dd -if -of`". Please
stop with that argument, as it really doesn't reflect reality.
That is
On 4/15/16 1:58 PM, Dmitry Stogov wrote:
A week ago, I actually wrote my own RFC
https://wiki.php.net/rfc/nullable_return_types
You proposed the ?Something grammar. With ?: and ?? appearing in recent
PHP and proposals for ??= if not ?:= and now this, I feel we're heading
to regex hell :p
T
On 4/14/16 3:50 AM, Dmitry Stogov wrote:
The up to date implementation for return-type-hints may be found at
https://github.com/php/php-src/pull/1851/files
Splendid!
Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1].
Tom
[1] https://wiki.php.net/rfc/nullable_returns
--
On 4/15/16 12:22 AM, Levi Morrison wrote:
My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.
For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
On 4/14/16 8:48 PM, Larry Garfield wrote:
I am highly, highly sceptical about nullable parameters or returns, and
frankly would rather they were not included in the language. By nature
they undermine type safety. At best, they indicate to all callers
"*every* time you call this function, you M
On 4/14/16 3:25 PM, Fleshgrinder wrote:
On 4/14/2016 8:59 PM, Stanislav Malyshev wrote:
>Hi!
>
>>I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>since it is super self-explanatory. However, I find myself checking the
>
>It may be self-explanatory for you. It's much le
On 4/13/16 5:06 PM, Stanislav Malyshev wrote:
Types are designed in a way enhancing the languages experience while
avoiding nearly every impact for people who want to ignore them.
This is not true. If it's in language, you have to understand it to be
able to use the language. Nobody writes cod
On 4/14/16, 5:46 PM, "Levi Morrison" wrote:
>Having a separate method instead of `foo(null, "value")` makes it
>difficult to use for the result of a function.
I suspect that might be a good thing:) I don't know for sure but the
possibility exists.
>Assume `bar()` returns
>`Bar | Null`; this wo
On 4/14/16, 1:33 PM, "Fleshgrinder" wrote:
>On 4/14/2016 6:35 PM, Levi Morrison wrote:
>>I can appreciate that you want only the restricted union with null.
>> However, I do not see the point of disallowing it for parameter types
>>
>My guess is that this RFC only wants to get it for return becau
On 4/14/16, 12:35 PM, "Levi Morrison" wrote:
>I can appreciate that you want only the restricted union with null.
>However, I do not see the point of disallowing it for parameter types
>while allowing it for return types:
>
>function setLeft(Node $n = null) {
>$this->left = $n;
>
On 4/13/16 11:46 PM, Levi Morrison wrote:
As alluded to in an earlier email today[1] I am now moving the Union
Types RFC[2] to the discussion phase. The short summary of the RFC is
that it permits a type declaration to be one of several enumerated
types.
I look forward to a helpful and meaning
I would like to introduce for discussion an RFC proposing and arguing for
Nullable Return Type Declaration in 7.1 and deferring for now more general
relaxations of 7.0 type as proposed in Levi's two RFCs.
https://wiki.php.net/rfc/nullable_returns
If anyone would like to collaborate on the RFC,
On 4/11/16 6:11 PM, Sara Golemon wrote:
On Mon, Apr 11, 2016 at 9:36 AM, Stanislav Malyshev wrote:
The point is even imperfect detection may be useful in certain
circumstances, and detector being part of ICU hints that people find it
useful enough to spend time implementing and supporting it. W
mathieuk has requested feedback on a patch to mitigate this problem in PHP.
https://bugs.php.net/bug.php?id=71915
Tom
Hi Daniel,
When I write scripts that need to behave the same independently of the
value of mbstring.func_overload then I have to remember to be careful
with the functions it affects. It's a drag. I resent having to write
things like mb_strlen($str, '8bit') to get a byte-count knowing that the
On 2/23/16 7:13 PM, Yasuo Ohgaki wrote:
>http://www.pcg-random.org/
It's simple and supports 64bit int out of the box.
Looks great!
PSG is very interesting. But it's new and hasn't been peer reviewed yet.
It's in the "experimental" stage while others are more "well known".
xorshift+ seems
I agree that mt_rand() should warn before delivering bogus outputs. But
when it works, it works ok:
https://gist.github.com/tom--/a12175047578b3ae9ef8
Given that it hasn't been MT19937 or many years, it probably doesn't
need to be.
If there is really a need for fast repeatable RNGs (the kind
embarrassing correction to my message: the last four words of the 2nd
para here should have been at the end of the previous para.
On 2/22/16 8:23 AM, Tom Worster wrote:
PHP is an unlikely language for the typical programs that specifically
need MT19937. I doubt we would sort out anyone&#
I ran mt_rand() through dieharder and it appears to perform well. I put
the results here:
https://gist.github.com/tom--/a12175047578b3ae9ef8
On 2/19/16 8:39 PM, Andrea Faulds wrote:
PHP's implementation of the Mersenne Twister algorithm is buggy, so it
doesn't produce the same output as in o
On 1/14/16, 9:37 AM, "Pierre Joye" wrote:
>I think we get every one point about where we stand, between the
>people against a CoC, against a CoC with teeth etc.
I wasn't talking about the Code of Conduct. Different topic.
>This is getting
>nowhere and we are really off topic.
>
>I would sugg
1 - 100 of 168 matches
Mail list logo
