Re: RFC: rules for #include directives

On Mon, 16 Jan 2023, Max Kellermann wrote: > On 2023/01/16 13:38, Kamil Tekiela <tekiela246@gmail.com> wrote: > > > What's the impact on other maintainers, especially extension > > maintainers? > > Other maintainers may need to determine which includes they really > need, instead of relying on everything always already there by > including one random zend_* header. Including a "random" zend header also sounds like a great benefit. I shouldn't need to care as an extension author which header enables which internal function(s) for usage. > Extension maintainers may see build failures because, for example, > they forgot to include errno.h but used "errno". This previously > worked because all PHP headers included errno.h even though there was > no reason to. These build failures are bugs in those extensions, and > revealing them is a good thing, even though it seems tedious at first. This is a very naive view of the world. You don't get to decide what is "good for other people". > > Do you see any downsides to your new approach? > … > Derick Rethans wrote my idea "adds nothing but clutter", but I guess > he should explain what bothers him; I don't comprehend this, because > from my perspective, I intend to remove clutter. When looking at the commit history, I saw more than a dozen commits doing a small change. That is clutter. Adding forwards declarations for zend_* structs, is clutter. Adding comments that go out of date as to why a header is included is also clutter. > Dmitry Stogov said it's "just a useless permutation", but I can't > understand this argument either. It creates code-churn, which makes merging up fixes from older branches harder. cheers, Derick