KF 5 & C++14?

[Friedrich W. H. Kossebau]

Am Montag, 27. April 2020, 00:45:41 CEST schrieb David Faure:
> On Sunday, April 26, 2020 5:30:37 PM CEST Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > I just saw that at least kimageformats, knewstuff & kquickcharts all set
> > this: set(CMAKE_CXX_STANDARD 14)
> > 
> >     set(CMAKE_CXX_STANDARD_REQUIRED ON)
> > 
> > Which ignores a bit that so far C++11 has been the minimum standard
> > officially supported in/by KDE Frameworks (by mainly following what Qt 5
> > supports).
> > 
> > Compare also the current text of the policy
> > "Frameworks compiler requirements and C++11":
> > --- 8< ---
> > The following minimal compiler versions are supported by KDE Frameworks:
> > * GCC 4.8
> > * Clang 3.3
> > * VS2013 (MSVC12)
> > 
> > This means all of the C++11 standards can be used.
> > --- 8< ---
> > * https://community.kde.org/Frameworks/
> > Policies#Frameworks_compiler_requirements_and_C.2B.2B11
> > 
> > What to make of this? Might it be the time to raise the bars a bit, and
> > how
> > much? Surely the lower limit is what the oldest Qt version currently
> > supported by KDE Frameworks claims to support:
> > https://doc.qt.io/qt-5.12/supported-platforms.html
> > 
> > Should we go above this?
> > Or should kimageformats, knewstuff & kquickcharts be fixed to use C++11
> > only again?
> > 
> > No own opinion, so far only stumbled over what seems a policy breakage.
> 
> The goal was to align with the requirements of the Qt version we require.
> 
> But it's hard to know if anyone is actually using gcc 4.8 to build the
> current version of KF5. One way to find out is to... do nothing. Leave the
> above as is and see if anyone actually complains that it doesn't match our
> promise.

For reference, the CMAKE_CXX_STANDARD 14 is present in those modules...
KQuickCharts:  since KF 5.65 (== addition of module)
KNewStuff:     since KF 5.69
KImageFormats: since KF 5.70
So relatively new, meaning the field observation phase only just began :)

> This isn't however a green light for doing this everywhere, not until we
> wait multiple months for feedback. Otherwise the porting effort (down to
> C++11) will be huge.

One personal motivation to ask was the hope that we could go C++14 across all 
KF modules now. Not needing to support C++11 anymore, but relying on C++14 
deprecation tagging features would simplify ECMGenerateExportHeader code and, 
what triggered me here, make it simple to extend version-based deprecation 
tagging also for enumerators.
Guess I am out of luck then for now, or have to post-pone the feature :)

Cheers
Friedrich