Changes between Version 1 and Version 2 of RFC/7_LanguageStandardsSupport

Timestamp:

Feb 26, 2021, 10:36:22 AM (3 years ago)

Author:

veroandreo

Comment:

minor cosmetics

RFC/7_LanguageStandardsSupport

@@ -9 +9 @@
 The code base of GRASS GIS consists today (Feb. 2021) of predominantly C code (ca 50 %), Python (ca 30 %) and a smaller amount of C++ (ca 5 %). Each of these languages have evolved significantly in the last 10–20 years. There is, however, no clearly stated policy of supported language standard(s), nor mechanism to update this policy when needed or wanted. This result in uncertainty for contributors for what may be allowed and solutions that may not be optimal.
 
-This RFC aims at setting a policy for the GRASS GIS project on language standard support for C and C++, as well as setting minimum version support of Python.
+This RFC aims at setting a policy for GRASS GIS project regarding language standard support for C and C++, as well as setting the minimum version support for Python.
 
 In addition, this is also intended to set a precedent for future updates on this subject.
 
 == Background ==
-Through its long history, soon 40 year, GRASS GIS has evolved and steps has been taken to adapt and modernize. The latest big modernization of the C code was done 2002–2006 ([https://lists.osgeo.org/pipermail/grass-dev/2021-February/094955.html summary]), when it was updated to conform to C89 (ANSI C) standard. A major job, which has payed-off well. However, language features of successive standards have during the years slipped into the code base, which is no longer strictly C89 (nor C90) conformant. There are no compelling reasons to revert the existing code to strict C89, therefore the community have to decide which standard to adhere to.
+Throughout its long history, soon 40 years, GRASS GIS has evolved and steps have been taken to adapt and modernize. The latest big modernization of the C code was done in 2002–2006 ([https://lists.osgeo.org/pipermail/grass-dev/2021-February/094955.html summary]), when it was updated to conform to C89 (ANSI C) standard. A major job, which has payed-off well. However, during the years, language features of successive standards have slipped into the code base, which is no longer strictly C89 (nor C90) conformant. There are no compelling reasons to revert the existing code to strict C89, therefore the community has to decide which standard to adhere to.
 
-Similarly, the integration of Python with GRASS GIS – driving the GUI and to a large extent replaced shell script (bash/sh)  for scripting – have been through a challenging period with the transition from Python 2 to 3. This transition can now be considered completed, but this fact need to be formalised and the minimum version of Python 3 support must be stated.
+Similarly, the integration of Python within GRASS GIS – driving the GUI and to a large extent replacing shell scripts (bash/sh) for scripting – has gone through a challenging period with the transition from Python 2 to 3. This transition can now be considered completed, but this fact need to be formalised and the minimum version of Python 3 support must be stated.
 
-The small C++ code in GRASS GIS has never been formalised and officially made to conform to any specific standard.
+The small amount of C++ code in GRASS GIS has never been formalised and officially made to conform to any specific standard.
 
 See also the discussion leading to this RFC on the mailing list [https://lists.osgeo.org/pipermail/grass-dev/2021-January/094899.html thread].
 
 == Discussion ==
-The advantage of having clearly stated policy on language standard requirements/support is important not only for contributors, but also sets the frame for supported platforms. For the latter, also the reverse is true: in deciding supported standard the community need to consider the degree of support of standards for various platforms.
+The advantage of having clearly stated policy on language standard requirements/support is important not only for contributors, but also sets the frame for supported platforms. For the latter, also the reverse is true: in deciding supported standard the community needs to consider the degree of support of standards for various platforms.
 
 It should be emphasized that existing GRASS GIS C and C++ code compiles also with C17 and C++17. There is therefore no need to modernize it the way it was done to C in the 2000’s. Nevertheless, conforming to newer standards may provide better cross platform support and possibly safer code.
 
-Regarding C, there are three standards that may be considered: C99, C11 and C17. C99 never really reached full support on key platforms, this particularly the case for Windows ([https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio-2013/ Visual Studio 2013]). Partly in consequence of this lack of support for some C99 features, the C11 standard was made less strict: making some C99 mandatory features optional. Thus, from autum 2020 even [https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ MSVC complies to C11] core feature support. Starting with [https://gcc.gnu.org/wiki/C11Status GCC 4.9] it had “substantially complete” support for C11, Clang from [https://releases.llvm.org/3.1/docs/ClangReleaseNotes.html version 3.1]. [https://en.wikipedia.org/wiki/C17_(C_standard_revision) C17] on the other hand doesn’t add new features compared to C11. Its difference is more intresting from compiler point of view, whereas code “good for C11” is good for C17.
+Regarding C, there are three standards that may be considered: C99, C11 and C17. C99 never really reached full support on key platforms, this is  particularly the case for Windows ([https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio-2013/ Visual Studio 2013]). Partly in consequence of this lack of support for some C99 features, the C11 standard was made less strict: making some C99 mandatory features optional. Thus, from autumn 2020 even [https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ MSVC complies to C11] core feature support. Starting with [https://gcc.gnu.org/wiki/C11Status GCC 4.9] it had “substantially complete” support for C11, Clang from [https://releases.llvm.org/3.1/docs/ClangReleaseNotes.html version 3.1]. [https://en.wikipedia.org/wiki/C17_(C_standard_revision) C17], on the other hand, doesn’t add new features compared to C11. Its difference is more interesting from compiler point of view, whereas code “good for C11” is good for C17.
 
 Regarding C++, there are the C++98, C++03, C++11, C++14 and C++17 standards to consider. The platform and compiler support for all of these are significantly better. However, C++11 is at this date in general considered the standard and until compelling reasons argue otherwise, the C++11 standard should be policy of the GRASS GIS project.
 
-The GRASS GIS support for a C and C++ standard, will most likely not be a subject to change too frequently. The minimum support for Python will, on contrast, likely change more often, due to each (minor) version’s 5-year life-time. At this date, the oldest still-alive Python version is 3.6, to be retired in December 2021.
+The GRASS GIS support for C and C++ standards will most likely not be a subject to change too frequently. The minimum support for Python will, in contrast, likely change more often, due to each (minor) version’s 5-years life-time. At this date, the oldest still-alive Python version is 3.6, to be retired in December 2021.
 
 == Proposed Language Standards Support ==