[PROJ] Updating our C++ requirement to C++17 for PROJ 9.6

[Kurt Schwehr]

Too strict and thanks Even for the motion.

On Mon, Jan 6, 2025 at 7:31 AM Kristian Evers <kristianevers at gmail.com>
wrote:

> Here’s a few excerpts from RFC3:
>
> A change in programming language standard can only be introduced with a
> new major version release of PROJ
>
>
>
^ And I missed that!


> That means that a change to C99 is possible, as long as the PROJ PSC
> acknowledges such a change.
>
>
> 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.
>
>
> 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.
>
> What do you guys think? Is the current version of RFC3 too strict?
>
> /Kristian
>
> On 6 Jan 2025, at 16.15, Kurt Schwehr via PROJ <proj at lists.osgeo.org>
> wrote:
>
> 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.
>
> If that's different from peoples' expectations, we should definitely
> discuss.
>
> If it were a motion, I'd definitely +1 for C++17.
>
> On Mon, Jan 6, 2025 at 6:49 AM Howard Butler via PROJ <
> proj at lists.osgeo.org> wrote:
>
>>
>>
>> > On Jan 2, 2025, at 5:54 PM, Even Rouault via PROJ <proj at lists.osgeo.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > Happy New Year!
>> >
>> > 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.
>> >
>> > Initial trigger for this move is explained in
>> https://github.com/OSGeo/PROJ/pull/4366. All our existing CI
>> configurations already satisfy the C++17 requirement (and one of them was
>> already testing C++20 compatibility)
>> >
>> > I don't anticipate much use of new capabilities for now except perhaps
>> replacing our internal::make_unique<> by C++14 std::make_unique<>
>> >
>> > C++17 has been a build requirement for GDAL since one year and nobody
>> complained. Cf
>> https://gdal.org/en/stable/development/rfc/rfc98_build_requirements_gdal_3_9.html
>> for an analysis of the impacts.
>> >
>> > This also satisfies https://proj.org/en/stable/community/rfc/rfc-3.html
>> 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.
>>
>>
>> Is this a PSC motion? +1 :)
>>
>> Howard
>> _______________________________________________
>> PROJ mailing list
>> PROJ at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/proj
>>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250106/c56fc60a/attachment.htm>