Use of wiki to explain planned / upcoming / recent changes

[m-holger]

I think it would make sense to make greater use of the qpdf wiki,

One of the areas where I think this would be useful is for highlighting and explaining changes. I see this as a complementing release notes and discussions - providing more detail than release notes can provide and providing a clearer and more structured view of what is currently planned.

I have drafted a couple of notes to illustrate what I have in mind.

[jberkenbilt]

Sorry, I completely overlooked this. I have no real objections to any of this. I haven't thought through it as deeply as you have, but nothing sounds any sirens. Your analysis of null/uninitialized seems thorough and has successfully incorporated all my previous concerns.

FWIW, I strongly dislike that C/C++ allow assignments to be used as conditionals and avoid that pattern in my own code. I think there are reasons why go and rust both reject that. I also don't like how non-boolean types can be treated like booleans (as in JavaScript's truthy and falsy). That said, I recognize that these are common C++ idioms, so I have no problem with your mentioning them in the wiki, and I wouldn't reject a PR that did those. I think g++ warns if you do it without an extra set of parentheses, or at least it did at one time. I don't know remember CLion and clang-format do in those cases or what the state of the current qpdf codebase is. But this is relatively insignificant and doesn't really have any bearing on any of this. I'm just spewing my opinions.

[m-holger]

Well, I don't like C++, but changing this for qpdf is not an option. With this constraint I view the pattern as the lesser of the evils. Usually avoiding it means either more non-local variables or deeper levels of nesting, both of which have a higher impact on readability, especially given how ingrained the pattern is.

I think g++ warns if you do it without an extra set of parentheses

I think it is common to warn on implicit conversion to bool. clang does this too if you try to use return 42; in a bool function.

Anyway, it would make sense to refer in the release notes 'Future' section to the to the wiki pages as a source of further info. Do we want to use wiki.qpdf.org urls for that?

[jberkenbilt]

Anyway, it would make sense to refer in the release notes 'Future' section to the to the wiki pages as a source of further info. Do we want to use wiki.qpdf.org urls for that?

We could do that. I never had the energy to deal with the wiki, particularly regarding who should be allowed to edit it, but I have no objection to your making better use of the wiki, and since FUTURE is, by nature, a moving target, it's reasonable to have the release notes point there rather than containing static information.

[jberkenbilt]

I replied in email, but I have no objection to your moving forward with the plan to use the wiki in this way. It's better to have these out in the open. We have several different channels, but the wiki seems better for working out notes than files committed to the main repo or discussions. You can try this and see if it does what you want.

I have skimmed but read the content in detail. Given my relatively low availability right now, it's best if you ask me targeted questions. If you need me to think deeply about something, review a design, etc., I'm happy to do it, but it will take me a while to get to it as you very well know.

Thanks again for all this effort and for breathing new life into qpdf.