Hi!
date_sunrise() and date_sunset()
Do we have any information on usage? I am generally not a fan of deprecating functions that work - even if they are odd and have quirky APIs - but if the usage is essentially zero than it might be ok.
key(), current(), next(), prev(), and reset() on objects
I'd be happier if those worked with iterators. Except for prev() which I don't think many people need.
mb_check_encoding() without argument
No objection.
get_class(), get_parent_class() and get_called_class() without argument
I'm not sure why. I mean if we want to make them return the same as self::class etc. - up to the point of actually compiling them as such - no problem, but I don't see why they need to be deprecated. And I vaguely remember seeing get_class() at least a bunch of times in old code, when ::class didn't even exist. I don't see a good reason why that code should be broken.
FILE_BINARY and FILE_TEXT constants
No objection.
t fopen mode
I'm afraid there's - despite the warning - a bunch of code for Windows that relies on "t" and I don't think we should be breaking it. Is there a good reason to drop this mode?
Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll()
Accessing static members on traits
No objection.
strptime()
strftime() and gmtstrftime()
We have to remember many applications do not need to be portable, as they will ever be only run on one setup - the one that the company running it has. So non-portability itself should not be a fatal problem. I am worried by musl thing mentioned - what exactly happens on musl, they don't have strptime()? If it's just different outputs or some options not supported, I think it's ok - warning in the docs should be enough.
mhash*() function family
No objection.
ctype_*() function family accepts int parameters
Here I think adding notice for int arguments would be appropriate, but changing the behavior is not - we could cause some very nasty breaks in the code if we suddenly change such a basic thing.
Return by reference with void type
NIL constant defined by the IMAP extension
No objection.
Calling overloaded pgsql functions without the connection argument
I hate global state, but there are a lot of old quick-n-dirty scripts relying on stuff like that. Can we maybe check how common is usage of this pattern?
$num_points parameter of image(open|filled)polygon
mysqli::init()
No objection.
--
Stas Malyshev
smalyshev@gmail.com