Upgrade to C++17

[mateofio]

Here is table of platform support. Once all platforms are on C++17 enabled compilers we can upgrade.

Platform	Compiler Version	C++17 Enabled
Windows	MSVC 19.x	✔️
Linux / emscripten / libretro	gcc 9	✔️
Mac OSX / BSD	clang 9	✔️
devkitPro (Wii, 3ds, switch)	gcc 10	✔️
PSP	gcc 9.3.0	✔️
PS Vita	gcc 9.1.0	✔️
MorphOS	gcc9	✔️
AmigaOS4	gcc8	✔️
BeOS (Haiku)	gcc7	✔️
AROS ABIv0	gcc6	❌
GCW Zero	gcc4.9	❌

[mateofio]

It's been a year and I'd like to revisit this.

It looks like GCW Zero has experiment support for gcc6 https://boards.dingoonity.org/gcw-development/gcw-zero-toolchain-for-windows-(cygwin)-2013-10-04/

This post was from 4 years ago. It seems likely this platform will remain stagnant forever. How long do we want to be held back by this one for new player development?

https://github.com/aros-development-team/AROS

AROS is still on gcc 6 but they have experimental gcc 9 and 10 for x86_64. Do we support all the hardware platforms on AROS?

[Ghabry]

How about after the next release? This will be in maybe 2-3 months?
Why after the next: This way everyone can profit from the significant improvements we did over the last year. (Events, battle, midi, translation etc...)

There is really no real movement anymore here. So gcc7 as the new low bar is fine to me.

Other opinions?

But I will not accept any new C++17 library features that interact with the underlying system. e.g. std::filesystem. We always have bad experiences with broken newlib implementations.

gcc <filesystem> support comes with gcc8, so it is not pretty usable yet (there's <experimental/filesystem> with gcc7 but as the name says, it's experimental, so...).

Current limitation is Haiku with gcc 7.

The c++17 support for other things looks sane, so +1 for the c++17 bump.

[carstene1ns]

I already removed the jenkins jobs for gcw0 a few days ago. If there ever is a new toolchain, we can always add them back. So gcc7 is ok from me. And it should come this year.

[carstene1ns]

About std::filesystem: tried it and works on switch at least.

[Ghabry]

okay then this is decided for "After the next release".
Also "After all big PRs are in" because the StringView -> std::string_view change will be otherwise mess. ;)

Where's the source of gcc7 requirement for Haiku? It seems there is some gcc8 on Haiku since 2018-2019. If that's correct, we could bump to gcc8 sooner.

[Ghabry]

@BSzili how is the current compiler situation on AmigaOS, AROS, etc?

[BSzili]

I think MorphOS and AmigaOS4 have up to date compilers with C++17 support, so there shouldn't be an issue there. AROS ABIv0 is unfortunately stuck with GCC6 and ABIv1 x86_64 is still not that stable, so it's a moving target. If AROS is the only platform blocking the C++17 transition, then it's probably the best to drop it until the ABIv1 branch is mature enough.

[Ghabry]

That discussion was more than 2 years ago so imo the baseline can shift again. In that table most compilers were already at gcc9 so they likely use gcc10 by now.

We could use a subset (!) of C++20 by targeting g++10. This adds support for std::span and std::string_view::(starts|ends)_with, allowing to remove some helpers we have.

[BSzili]

I checked and both MorphOS and AmigaOS4 has GCC 11.2.0 now.

[Ghabry]

@fdelapena If there are no objections I would increase this to C++17 now for liblcf and Player.

There is no code really needing it right now, is just a "because we can"

It looks safe to bump, so looks good to me 👍.