<div dir="ltr"><div>Interestingly for GDAL there was no mayor release needed (or we did not realize it).</div><div><br></div><div>Something that is not discussed is if the new features of C++17 can be used in the API, or only in internally in the implementation. In a GDAL PSC meeting we decided the latter (no C++17 new features in the C++ API, but I do not remember if it was written anywhere).</div><div><br></div><div>I am fine with both, update to C++17, and change RFC3 if needed.<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 6 Jan 2025 at 16:31, Kristian Evers via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Here’s a few excerpts from RFC3:<div><br></div><div><blockquote type="cite">A change in programming language standard can only be introduced with a new major version release of PROJ</blockquote><div><br></div><div><blockquote type="cite">That means that a change to C99 is possible, as long as the PROJ PSC acknowledges such a change.</blockquote><br></div><div><blockquote type="cite">When a new standard for either C or C++ is released PROJ should consider changing its requirement to the next standard in the line. For C++ that means a change in standard roughly every three years, for C the periods between standard updates is expected to be longer. Adaptation of new programming language standards should be coordinated with a major version release of PROJ.</blockquote></div><div><br></div><div>The first excerpt says we can’t make this change until PROJ 10.0.0 is released. The second excerpt states that the PSC should acknowledge a change in which version of either C or C++ is used. And the last encourages us to reconsider the dependencies once in a while. These may not go particularly well together and were written at a time where we did rather frequent major version updates. So maybe a first step is a revision to RFC3 so it allows os to change the minimum version of C and C++ without a major version release of PROJ. It could easily be a number of years before we go to PROJ 10.</div><div><br></div><div>What do you guys think? Is the current version of RFC3 too strict?</div><div><br></div><div>/Kristian</div><div><br><blockquote type="cite"><div>On 6 Jan 2025, at 16.15, Kurt Schwehr via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">I take RFC 3's text as meaning that there doesn't need to be a vote with this switch, but that it's a nice thing for the person doing the update to let the list know of the change happening. If the project wants to switch to C++23, that would imply that a motion is needed.</div><div dir="ltr"><div><br></div><div>If that's different from peoples' expectations, we should definitely discuss.</div><div><br></div><div>If it were a motion, I'd definitely +1 for C++17.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 6, 2025 at 6:49 AM Howard Butler via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jan 2, 2025, at 5:54 PM, Even Rouault via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> Happy New Year!<br>
> <br>
> I propose we update our build requirement from C++11 to C++17. This should hopefully be unnoticed by anyone using a not too antiquated build chain.<br>
> <br>
> Initial trigger for this move is explained in <a href="https://github.com/OSGeo/PROJ/pull/4366" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/4366</a>. All our existing CI configurations already satisfy the C++17 requirement (and one of them was already testing C++20 compatibility)<br>
> <br>
> I don't anticipate much use of new capabilities for now except perhaps replacing our internal::make_unique<> by C++14 std::make_unique<><br>
> <br>
> C++17 has been a build requirement for GDAL since one year and nobody complained. Cf <a href="https://gdal.org/en/stable/development/rfc/rfc98_build_requirements_gdal_3_9.html" rel="noreferrer" target="_blank">https://gdal.org/en/stable/development/rfc/rfc98_build_requirements_gdal_3_9.html</a> for an analysis of the impacts.<br>
> <br>
> This also satisfies <a href="https://proj.org/en/stable/community/rfc/rfc-3.html" rel="noreferrer" target="_blank">https://proj.org/en/stable/community/rfc/rfc-3.html</a> which mentions "Keeping a policy of always lagging behind be two iterations of the standard is thought to be the best comprise between the two concerns", given that C++20 and C++23 are out.<br>
<br>
<br>
Is this a PSC motion? +1 :)<br>
<br>
Howard<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div></div>
_______________________________________________<br>PROJ mailing list<br><a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>