> On May 2, 2020, at 13:57, AllenJB <php.li...@allenjb.me.uk> wrote: > > Hi all, > > I'd like to discuss deprecating uniqid() > > I believe it's dangerously bad a doing "what it says on the tin". New > developers still reach for it and do not read the warnings on the manual page > (or if they do, don't fully understand how bad it is). > > For older codebases that still rely on it, a userland replacement can be > easily implemented (and could be published on Packagist). > > I noticed there was an RFC [0][1] brought up 2 years ago, but was never voted > on. Does anyone know why this was? > > [0] https://externals.io/message/102097 > [1] https://wiki.php.net/rfc/deprecate-uniqid > > Is there interest in deprecating this function? > > If not deprecation, how could it be (further) "improved"? My first thought is > to make the "more entropy" option enabled by default (the argument could > remain so that it can be disabled by codebases that rely on the lower length > and can take the tradeoffs).
Instead of deprecating and removing it, would anyone be opposed to replacing the internals of the function so that it uses `random_bytes()` under the hood, while all other functionality remains the same? Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
