On Friday, 31 October 2025 at 11:11, Tim Düsterhus <[email protected]> wrote:
> Hi > > Am 2025-10-31 10:29, schrieb Alexandre Daubois: > > > If no concerns are raised in the next few days, I'll open this RFC to > > the vote in its current state. > > > I will vote against the RFC in its current state for the reasons that I > outlined before. > > It's needlessly diverging from Perl by inventing new letters that are > not even internally consistent with the existing letters (lowercase vs > uppercase is 16 bit vs 32 bit, not LE vs BE). It is also still making > the false statement that Perl's approach doesn't work for PHP when we > established during the discussion that it does work, if we want it to > work. It's also needlessly confusing the reader by including information > about a PR #19368 implementation that can easily be mistaken for > something that is already an established fact rather than a proposal. > > Best regards > Tim Düsterhus We do use lowercase/uppercase as an indicator for BE/LE for float specifiers, something Perl does not support. However, the h (and b in Perl) specifiers use the case to indicate if it is the low or high nibble first. Moreover, Perl and PHP primarily use cases to distinguish between signed and unsigned for integer specifiers, namely the s, l, q, i (and j for Perl) specifiers. Only the n and v specifiers use uppercase to mean 32 bit instead of 16. So there isn't a true "meaning" behind what upper and lowercase means, be that in Perl or in PHP. While the < > syntax to "force" the endianess of a sequence specifier is nice. But if this requires rewriting the whole parser as this RFC implies, then you are asking someone to commit to a larger amount of work than they signed up, which is considered bad RFC etiquette. [1] Still stating your reason for rejecting an RFC is a nice heads up. The strongest argument for introducing the < and > specifiers is that Python [2] does it that way, but a key distinction is that it is the *only* way to specify endianess. And if this would be a new parser/API we might as well do other changes such as using a + or - specifier to indicate signedness, and add grouping using () like Perl. Overall I am +-0 on this RFC because I don't use those functions, so I'll abstain from it. Best regards, Gina P. Banyard [1] https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md#dont-volunteer-other-people-for-huge-amounts-of-work [2] https://docs.python.org/3/library/struct.html#struct-alignment
