Re: int|float for sleep? sleep(0.1) => sleep 0.1 seconds

Hi On 3/5/24 14:09, Hans Henrik Bergan wrote:

I don't want to spend too much effort on nitpicks, but if someone volunteers to improve it, I'd be happy to add it, in which case please send a PR to https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md

To set my email in context: For me visuals play an important role in the overall presentation of an RFC. If it's not properly formatted, it's harder to read and harder to understand the RFC. Proper formatting also is some indicator that the author actually cares about the RFC instead of just throwing stuff over the fence and letting others figure out the details. This one is simple enough and it's certainly not something that makes me vote “No” out of spite, but perhaps this is something to keep in mind for future RFCs.

For (2) it would help if you'd explain what it means for sleep() to be

interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, […] I don't know how to make it return 192 on Windows.. Anyone know?

My remark was not just about Windows (I can't advice here either, I don't do Windows), adding a short *nix explanation of when sleep will return earlier than expected would be helpful as well. That's likely the more common case anyway.

I'd just put a single "Do all of this in the next minor" vote there. All of the suggested improvements make sense to me and the breaking changes are mostly theoretical.

meh, I don't want to risk the RFC getting rejected because too many people thought it should be done in next.major instead of next.minor, let's keep both next.minor + next.major vote options. (You're probably right, I predict a majority vote for next.minor for all 3, but i'll keep the vote options just in case.)

Complicated voting options also risk the RFC getting rejected, especially if certain combinations of voting options are non-sense (such as 1: yes, 2: yes, 3: no). Personally I'd rather have no change at all, instead of a half-baked internally inconsistent change.

Don't forgot to open up a dedicated explicit discussion thread once you move it into the "Discussion" phase.

How would I even do that? Linking to https://externals.io/message/122388 isn't sufficient?

Once you are happy with the RFC contents, instead of replying to this existing thread, send a fresh email to the list, titled "RFC: Support for Floats in Sleep Function", in there link the RFC and this discussion thread and say that the discussion period is starting now. This will ensure it will pop up as a fresh email for the folks who already ignored the subthread, because they were not interested in the pre-RFC discussion while stuff is still in flux. Best regards Tim Düsterhus