Discussion :

[wolinn]

qu'est ce que j'aimerais qu'il y ait un nettoyage de la syntaxe du c++, le langage est bien, mais stupidement complexe à écrire, et plus ça va, plus on ajoute des syntaxes illogiques sur un socle stupide ;
les excuses habituelles de la rétrocompatibilité et de faire évoluer son code ne tiennent pas une seule seconde.

qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)

combien de fois j'ai lu des articles de pontes du c++ qui disent que la syntaxe pour telle fonctionnalité est stupide.

je vois souvent des moqueries sur la syntaxe de javascript, bah ça y est, on a les mêmes absurdités en c++.

on rajoute des fonctionnalités à c++, cool, mais à quel prix en terme d'écriture...

On n'est pas non plus obligé de tout utiliser...
En ce qui me concerne, j'ai toujours évité les constructions et syntaxes un peu bizarres dégradant la lisibilité.
Pour ce qui est de la rétrocompatibilité, j'apprécie bien que certaines portions de mes bibliothèques écrites vers 1995 soient toujours compilables, sans même un warning.
Je pense que briser la compatibilité serait assez dangereux pour l'avenir du langage, tant il y a de bibliothèques qui en dépendent, c'est un coup à diviser le langage en deux branches, et à le tuer.
La pérennité et la stabilité d'un langage sur le long terme est un critère très important pour les éditeurs de logiciel, on a autre chose à faire que reprendre des centaines de milliers, voire des millions de lignes de programme fiabilisées depuis longtemps à chaque changement de norme.

[stardeath]

bah dans ce cas, le c++ n'est pas un bon candidat, vu que comme je mentionnais, il y a des changements qui cassent la rétrocompatibilité.

de plus tant que les binaires finaux sont compatibles, je vois pas en quoi casser la syntaxe change la donne.
en plus comme j'ai mentionné, cette histoire de compatibilité, pour moi c'est du bullshit complet, ce qu'on exécute, c'est jamais le langage en lui même, mais des transformations de celui ci ; c'est que les transformations restent compatibles entre elles qui est important.
avec des projets comme llvm ou la suite gnu compiler c'est encore plus flagrant, tant que tu es capable de faire un front-end pour ton langage, techniquement, tu peux mélanger tous les langages de la terre dans une seule application.

donc de là, avoir des versions de langages c++ différentes dans une seule application, et faire évoluer un projet d'une syntaxe c++X à une syntaxe c++Y qui diffère, c'est faisable, le tout en gardant l'ancien code fonctionnel, et les nouvelles features dans une version remaniée de la syntaxe.

pour les éditeurs logiciels pour lesquels j'ai travaillé, ils étaient plus préoccupés par leur capacité à embaucher, plus que par la version des langages qu'ils utilisent, dans les dernières boites dans lesquelles j'ai bossé, ils mélangeaient allègrement c++, c# winform et c# xaml (dans la même application), puisque de moins en moins de dev sur le marché veulent faire du c++ et que les winform c'est ringard, donc bon, la pérennité, c'est pas leur problème, ils veulent surtout que le soft fonctionne et qu'ils trouvent des gens pour faire la maintenance.

[Invité]

bah dans ce cas, le c++ n'est pas un bon candidat, vu que comme je mentionnais, il y a des changements qui cassent la rétrocompatibilité.

Lesquels ? Dans la super-faq, ils disent que "C++11 a une compatibilité presque parfaite avec C++98/03" (https://isocpp.org/wiki/faq/cpp11#cpp11-learn).

en plus comme j'ai mentionné, cette histoire de compatibilité, pour moi c'est du bullshit complet

C'est bien. Mais figure-toi que tu n'es pas le seul programmeur C++ du monde et que certains ont besoin de retro-compatibilité ou de compatibilité avec le C. Et si tu ne me crois pas, va voir du côté de Python : ça fait bien 10 ans qu'ils essaient de migrer de 2 vers 3...

donc de là, avoir des versions de langages c++ différentes dans une seule application, et faire évoluer un projet d'une syntaxe c++X à une syntaxe c++Y qui diffère, c'est faisable, le tout en gardant l'ancien code fonctionnel, et les nouvelles features dans une version remaniée de la syntaxe.

Perso, j'en ai vraiment rien à faire que le override soit au début ou à la fin de la ligne. Si pour toi le plus gros problème de C++, c'est sa syntaxe bah c'est que le langage te convient plutôt bien sur tout le reste...

[stardeath]

Lesquels ? Dans la super-faq, ils disent que "C++11 a une compatibilité presque parfaite avec C++98/03" (https://isocpp.org/wiki/faq/cpp11#cpp11-learn).

tu le dis toi même, presque parfaite, et ton lien donne même un exemple : auto ;
c'est pile ce que je dis, des fois le comité casse, des fois il contourne.

C'est bien. Mais figure-toi que tu n'es pas le seul programmeur C++ du monde et que certains ont besoin de retro-compatibilité ou de compatibilité avec le C. Et si tu ne me crois pas, va voir du côté de Python : ça fait bien 10 ans qu'ils essaient de migrer de 2 vers 3...

donc mes questions vont être :
- quelle est l'intérêt d'une compatibilité de syntaxe avec le c89 ?
- quelle est l'intérêt d'une compatibilité de syntaxe avec c++98 ?
etc. etc.

et surtout qu'est ce qui, avec ma propal, va t'empêcher de compiler ton morceau de code c89 si tu es capable de dire au compilo que c'est du c89? c++98? "mon" c++ avec une syntaxe corrigée?

ôte moi d'un doute, j'ai pas dit ne plus être capable de compiler du vieux code, j'ai dit pouvoir indiquer au compilateur la version du langage à utiliser par, par exemple, unité de compilation ou autre. non?

si tu parles de compatibilité sur l'organisation des données en mémoire, cool, c'est ce que je dis aussi, si tu parles de la compatibilité de syntaxe qui, comme tu le soulignes toi même, n'est pas parfaite, c'est inutile.

python est l'exemple parfait du truc à ne pas faire, garder un semblant de compatibilité et continuer à mettre à jour les anciennes versions, pourquoi évoluer puisque les créateurs nous laisse le choix de ne pas le faire?
j'ai eut ça chez un client qui n'a jamais été capable de me dire quelle version de python était installée sur ces machines de prod, résultat, 4 versions d'un même script, en régressant les fonctionnalités que j'utilisais jusqu'à ce qu'il me dise que ça fonctionne, trop bien ...

Perso, j'en ai vraiment rien à faire que le override soit au début ou à la fin de la ligne. Si pour toi le plus gros problème de C++, c'est sa syntaxe bah c'est que le langage te convient plutôt bien sur tout le reste...

et donc? dans ce cas, pourquoi vouloir une amélioration, si le seul intérêt c'est que ça convient bien sur tout le reste?
après si on doit accepter toutes les idioties sans jamais pouvoir émettre de critique, je peux rien faire pour ça.

c'est quand même fou qu'on ne puisse plus émettre de critique, même sur un truc qu'on apprécie, je comprend pas cette mentalité.

ps: un langage, c'est grosso modo ses fonctionnalités et sa manière de les écrire, si ce qui me dérange c'est la syntaxe, ça fait quand même 50% du grosso modo qui me va pas. mais bon...
ps2: et je ne suis pas le seul dév c++ à émettre des critiques sur la stupidité de certains choix du comité, mais bon, c'est pareil...

[Pyramidev]

Lesquels ? Dans la super-faq, ils disent que "C++11 a une compatibilité presque parfaite avec C++98/03"

Les cassements de rétrocompatibilité les plus visibles sont en C++17.
Dans la bibliothèque standard, ce qui a été rendu obsolète en C++11 a été supprimé du C++17, par exemple std::auto_ptr qu'il faut remplacer par std::unique_ptr.

Cela m'a emmerdé quand j'ai voulu utiliser Boost.Locale qui, dans la version 1.66.0, contenait encore plein de std::auto_ptr. Je n'ai pas regardé s'ils ont mis à jour ce code depuis.

Si tu lis la documentation de l'entête <functional>, tu verras aussi plein de « (deprecated in C++11)(removed in C++17) » et quelques « (deprecated in C++17)(removed in C++20) ».

En C++, dans les rares cas où le code ne dépend que de la bibliothèque standard, c'est facile de mettre à jour le code pour le rendre compatible avec la nouvelle version du C++, car les cassements de rétrocompatibilité sont toujours peu nombreux. Par contre, quand on utilise des bibliothèques externes qui ont un vieux code qui marche, les cassements de rétrocompatibilité sont ennuyeux.

Du coup, en pratique, les compilateurs C++ permettent de tricher et supportent quand même des fonctionnalités retirées si on choisit les bonnes options de compilation.

[Pyramidev]

et surtout qu'est ce qui, avec ma propal, va t'empêcher de compiler ton morceau de code c89 si tu es capable de dire au compilo que c'est du c89? c++98? "mon" c++ avec une syntaxe corrigée?

ôte moi d'un doute, j'ai pas dit ne plus être capable de compiler du vieux code, j'ai dit pouvoir indiquer au compilateur la version du langage à utiliser par, par exemple, unité de compilation ou autre.

Dans l'état actuel, le faire au niveau des unités de compilation serait une mauvaise idée, car il y a trop de code partagé entre plusieurs unités de compilation, à cause des #include.

Ton idée me semble intéressante quand on utilisera import à la place de #include, mais les modules ne seront disponibles qu'à partir du C++20.

[stardeath]

#include est en effet possiblement un problème, vu le nombre de fois où j'ai vu des includes de .cpp pour ce que j'ai vu de pire.

après, pour moi toujours, si il y a trop de code partagé à cause des includes, c'est déjà un problème de cloisonnement.

mais bon, rien est magique, le problème étant que plus on attendra, plus on trouvera des excuses pour ne rien faire.
après c'est peut être une volonté, vu qu'il devient de plus en plus facile de faire des front-end avec gcc ou llvm, chacun pourra faire son langage tambouille qui transpilera en c++ ou compilera en binaire compatible avec c++.

[Invité]

...
ps2: et je ne suis pas le seul dév c++ à émettre des critiques sur la stupidité de certains choix du comité, mais bon, c'est pareil...

C'est pas la peine d'être aussi agressif. Va plutôt proposer tes idées au comité de normalisation au lieu de prendre tes goûts et besoins pour des généralités et de râler dans ton coin. Salut.

[stardeath]

C'est pas la peine d'être aussi agressif. Va plutôt proposer tes idées au comité de normalisation au lieu de prendre tes goûts et besoins pour des généralités et de râler dans ton coin. Salut.

déjà fait, déjà refusé.
quant à cette prétendu généralisation, sutter et stroustrup on déjà plusieurs fois fait des remarques sur les syntaxes a minima bizarre qui sortaient des discussions du comité.

mais bon, une fois de plus, on prétend que je suis le seul à remonter ça, et on ose dire que je suis agressif.

[Pyramidev]

À part ça, pour rebondir sur la proposition de stardeath, c'est ce genre de tactique qui a été utilisé en JavaScript avec le mode strict.

En gros, on a d'un côté le mode non strict (sloppy mode) qui est ultra permissif et, depuis ES5, on a un nouveau mode, le mode strict, qui est toujours ultra permissif, mais un peu moins. En écrivant "use strict";, on signale qu'on est en mode strict.
En ES6 (alias ECMAScript 2015) sont apparus les classes et les modules dont le code est automatiquement en mode strict. Du coup, cela permet d'avoir facilement les restrictions du mode strict dans le nouveau code sans sacrifier la rétrocompatibilité de l'ancien code.

[stardeath]

j'ai l'impression que c'est la tendance du moment pour beaucoup de langage d'avoir des outils et/ou possibilité pour resserrer les vis.
il y a des linter pour beaucoup de langages de programmation, sous visual studio (vs code aussi et sûrement d'autre ide), les pratiques jugées mauvaises, sont signalées de manière plus virulente qu'avant, etc.

[Invité]

À part ça, pour rebondir sur la proposition de stardeath, c'est ce genre de tactique qui a été utilisé en JavaScript avec le mode strict.

En gros, on a d'un côté le mode non strict (sloppy mode) qui est ultra permissif et, depuis ES5, on a un nouveau mode, le mode strict, qui est toujours ultra permissif, mais un peu moins. En écrivant "use strict";, on signale qu'on est en mode strict.
En ES6 (alias ECMAScript 2015) sont apparus les classes et les modules dont le code est automatiquement en mode strict. Du coup, cela permet d'avoir facilement les restrictions du mode strict dans le nouveau code sans sacrifier la rétrocompatibilité de l'ancien code.

Il me semble qu'en haskell, on peut même activer une à une les extensions que l'on veut utiliser : https://wiki.haskell.org/Language_extensions

[TawalMc]

Anh le C# voilà , j'oubliais qu'il continue d'exister (https://www.developpez.net/forums/im...ilies/ptdr.gif). Bof de là à vouloir mettre C# devant le C++, bof c'est vraiment osé. Laisse le C# avec son concurrent Java qu'il n'arrive pas encore à surpasser avant d'en venir au C++. Un langage qui est presque restreitn à une plateforme bof. Et dire qu'il ya des dommaines où il est presque inexistant et ne fait pas le poids une seconde face au Cpp.
J'aimerais bien voir Julia et ses évolutions !!
Tous les concureents possible , mais pas C# svp...
Vive l'évolution dun C++ , et vive ses concurrents (espéront qu'ils tiennent). https://www.developpez.net/forums/im.../icon_cool.gif

[Mingolito]

C# est maintenant plus ou moins multiplateformes (avec Xamarin, mono, etc).
En France C# est devant C++ sur les offres d'emploi.



Bon enfin trollage à part C++ reste le langage de choix pour les éditeurs de logiciels et certains domaines d'applications...

[Aurelien.Regat-Barrel]

qu'est ce qui est passé par la tête du comité pour se dire que par exemple ça : virtual int foo() override
c'est acceptable niveau syntaxe? (et ça c'est encore gentillet comme exemple de stupidité)

cette syntaxe est déconseillé par les guidelines officielles C++ (c'est à dire par le comité):
https://github.com/isocpp/CppCoreGui...md#Rh-override
un outil tel que clang-tidy peut automatiquement détecter et même transformer ce genre de cas.

Après c'est bien de troller sur l'emplacement d'un mot-clé, mais C++ possède aussi ses atouts même au niveau syntaxique (compare comment créer une map de tuples par exemple...). C++ permet de se passer plus facilement des pointeurs que pas mal d'autres langages, dont certains imposent même la virtualité sur chaque méthode... c'est quand même délirant.

Pour ce qui est de la rétrocompatibilité, C++ considère que c'est une feature. Sur de petits projets (de l'ordre de 100.000 lignes) cela peut paraître inutile, mais sur de gros projets (plusieurs missions de LOC) on voit les choses différemment... et des projets de 15 ans d'âge / plusieurs millions de lignes en C++, il y en a... beaucoup. C'est là une différente importante avec beaucoup d'autres langages.

[gl]

Pour ce qui est de la rétrocompatibilité, C++ considère que c'est une feature.

Tout à fait. Par contre, et juste pour préciser suite aux remarques de stardeath concernant les précédentes ruptures de compatibilité, contrairement à nombre d'autres langages visant la rétrocompatibilité le comité C++ me semble viser une compatibilité en pratique et non en théorie. Ce que je veux dire par là, c'est qu'au fil des versions la compatibilité a belle et bien été cassée sur le papier (export template, auto, trigraphes, auto_ptr, ...) mais qu'en pratique ce n'est pas problématique ou seulement à la marge [1] car il s'agit à chaque fois de fonctionnalité quasi absente des compilateurs (export template), utilisée par personne (ancienne sémantique d'auto, trigraphe), transformable automatiquement [2] (auto_ptr ==> unique_ptr) et le plus souvent via une durée de dépréciation raisonnablement longue par rapport à l'effort nécessaire au changement. Voire le plus souvent un mélange de tout ça.

Le gros problème de ces ruptures de compatibilité, c'est lorsqu'elles cassent dans des dépendances tierces, en particulier sur des dépendances header only.



[1] Enfin, à supposer que le programme soit correct et conforme aux idiomes et bonnes pratiques du C++, dans le cas contraire ça peut être plus douloureux. Mais ce n'est certainement pas le plus gros problème de tels codes et les adaptations nécessaires ne peuvent qu'être bénéfiques.
[2] Et dans les faits, des outils comme Clang-Tidy propose effectivement de telles transformations.

[gl]

pour reprendre mon example, virtual int foo() override, avec le virtual devant (l'omettre est pour moi une très mauvaise pratique, vu que le override est ailleurs dans le code) les mots clés/mots clés contextuels donnant des informations sur un seul aspect du langage sont à 2 endroits différents dans le code, totalement en contradiction avec le simple fait d'écrire au même endroit les trucs qui concerne la même chose.

Je comprends ce qui te gênes, et je suis d'accord que c'est regrettable. Mais j'ai quand même du mal à trouver ça réellement grave ou gênant.

[stardeath]

cette syntaxe est déconseillé par les guidelines officielles C++ (c'est à dire par le comité)

sauf que les mots clés ne se placent pas au même endroit, donc c'est cool si tu as un nom de fonction suffisamment court ou autre, mais dans le cas contraire ...
donc oui c'est déconseillé, mais c'est surtout (pour moi) parce que ça transparaît d'absurdités quand les 2 termes nécessaires à avoir l'ensemble des infos sont écrit diamétralement opposé (et je vois passer beaucoup de code où justement il y a les 2 pour cette seule raison).
et en parlant de ce cas particulier, puisque c'est une bonne pratique de les mettre, pourquoi finalement ne pas les imposer? les bonnes pratiques ne sont que des pratiques, donc bonne chance pour les imposer.

et, perso, si on doit en mettre qu'un, j'aurais été le premier content à écrire "override void toto()".

https://github.com/isocpp/CppCoreGui...md#Rh-override
un outil tel que clang-tidy peut automatiquement détecter et même transformer ce genre de cas.

oui, sauf que je pense que vous l'aurez compris, pour moi ça devrait faire parti du langage, pas des outils à coté, très utile il est vrai, mais si les gens ne les utilisent pas, tu ne peux pas les forcer.

Après c'est bien de troller sur l'emplacement d'un mot-clé, mais C++ possède aussi ses atouts même au niveau syntaxique (compare comment créer une map de tuples par exemple...). C++ permet de se passer plus facilement des pointeurs que pas mal d'autres langages, dont certains imposent même la virtualité sur chaque méthode... c'est quand même délirant.

on va encore dire que je m'énerve, mais en quoi c'est du troll?, c'est fou quand même une fois de plus cette propension à dénigrer les propos auquel vous n'adhérez pas, de plus, on est pas sur d'autre langage, on est sur le c++. donc si vous ne voulez pas argumenter ou autre, abstenez vous, vous verrez c'est encore plus facile que d'essayer de tourner en dérision des propos ...
et même, donc on met un truc bien pour faire passer la pilule du truc moins bien? c'est quoi cette logique?

Pour ce qui est de la rétrocompatibilité, C++ considère que c'est une feature. Sur de petits projets (de l'ordre de 100.000 lignes) cela peut paraître inutile, mais sur de gros projets (plusieurs missions de LOC) on voit les choses différemment... et des projets de 15 ans d'âge / plusieurs millions de lignes en C++, il y en a... beaucoup. C'est là une différente importante avec beaucoup d'autres langages.

une fois de plus, je ne dis pas ne plus être capable de compiler l'ancien code, je dis écrire le nouveau code et porter des améliorations avec un langage plus clair et moins alambiqué.
de plus merci, mais les projets historiques je connais, et j'apprécie grandement quand je lis le code de ne pas tomber sur des trucs alambiqués. pour continuer, on écrit rarement du code pour soi, alors avoir un langage qui impose un petit peu de formalisme, ça ne peut pas faire du mal, pour soi tout d'abord, et pour celui qui aura à faire la maintenance (bien que je vois de plus en plus du "je m'en foutisme" de ce coté là ; pourquoi faire un effort sur le code vu que dans X temps je serai "dans une autre équipe"/"dans une autre entreprise", rayer la mention inutile).

auto_ptr ==> unique_ptr

ça c'est typiquement le cas où ce n'est pas du tout automatique, la sémantique des 2 est totalement différente, et l'étape d'édition de lien ne réagit pas pareil quand tu as les bibliothèques qui utilisent ces pointeurs intelligent, dans un précédent poste on a eut des rollbacks vers auto_ptr assez violent à cause de la différence de fonctionnement entre ces 2 pointeurs.
donc ça non, le jour où ça sera supprimé du c++, je sais déjà où toquer si je souhaite me proposer pour faire la migration.

Je comprends ce qui te gênes, et je suis d'accord que c'est regrettable. Mais j'ai quand même du mal à trouver ça réellement grave ou gênant.

on est d'accord, c'est regrettable, pour moi le problème réel est que ça ne fera que s'accentuer au fur et à mesure des nouvelles releases du c++, et c'est un truc que j'ai pas forcément envie de ça arrive. comme je disais un peu plus tôt, j'écris des outils d'analyses du code c++, je sais pas si vous imaginez le bordel que c'est de gérer le simple cas du virtual/override/final ; le tout avec un bénéfice de la rétrocompatibilité syntaxique, pour moi, nul.

donc bon, réduire la grammaire et la spec de cas semblables, je dirai pas non.

[gl]

ça c'est typiquement le cas où ce n'est pas du tout automatique, la sémantique des 2 est totalement différente, et l'étape d'édition de lien ne réagit pas pareil quand tu as les bibliothèques qui utilisent ces pointeurs intelligent, dans un précédent poste on a eut des rollbacks vers auto_ptr assez violent à cause de la différence de fonctionnement entre ces 2 pointeurs.
donc ça non, le jour où ça sera supprimé du c++, je sais déjà où toquer si je souhaite me proposer pour faire la migration.

Les sémantiques sont différentes mais, hors cas de figure très particuliers, casser la compatibilité avec la perte du transfert implicite de propriété de l'auto_ptr est signe de code douteux. Et pour les cas particuliers, move devrait convenir mais là on n'est effectivement plus dans la conversion automatique.
En fait, la détection du problème de design des auto_ptr a été assez vite comprise et globalement les bonnes pratiques ont pris en compte assez tôt ce soucis ce qui limite fortement les cas problématiques (au moins dans mes domaines d'activité). Après si tu utilises une bibliothèque tierce qui les utilise y compris pour leur transfert de responsabilité, c'est effectivement très impactant. Mais je doute qu'il y ait encore beaucoup de bibliothèques tierces activement maintenues qui utilisent encore auto_ptr dans leurs dernières versions [1].

Au passage, auto_ptr est déjà supprimé (C++17).

on est d'accord, c'est regrettable, pour moi le problème réel est que ça ne fera que s'accentuer au fur et à mesure des nouvelles releases du c++, et c'est un truc que j'ai pas forcément envie de ça arrive. comme je disais un peu plus tôt, j'écris des outils d'analyses du code c++, je sais pas si vous imaginez le bordel que c'est de gérer le simple cas du virtual/override/final ; le tout avec un bénéfice de la rétrocompatibilité syntaxique, pour moi, nul.

donc bon, réduire la grammaire et la spec de cas semblables, je dirai pas non.

Je pense que le but des mot-clés contextuel comme override et final est de pouvoir rajouter ce type de fonctionnalité sans rajouter de mot-clés dans le langage et que c'est appelé à devenir la manière classique de décorer les prototypes de fonctions membres (et c'est d'ailleurs une syntaxe déjà présente avec const), dans le contexte c'est virtual qui a un emplacement particulier et je ne serais pas surpris que dans une version ultérieure virtual puisse retrouver après la fonction, comme override ou final.

Concernant les outils d'analyse de code C++, oui c'est galère et ce n'est pas nouveau depuis C++98 c'est compliqué (ce qui explique en grande partie qu'il n'y ait que peu de fonctionnalité de refactoring automatique dans les EDI C++ en comparaison de ce qui est proposé par d'autres langages). Mais LLVM/Clang semble avoir apporté une vrai simplification à ce niveau et ce qu'arrive à faire Clang-Tidy est assez bluffant (après travailler sur l'AST plutôt que sur le code textuel semble aider beaucoup).



[1] Et les cas où les dernières versions ne seraient pas disponibles (ce que je connais très bien) ne posent généralement pas vraiment de souci car les compilateurs sont encore plus à la bourre.

[Bousk]

les 2 termes nécessaires à avoir l'ensemble des infos sont écrit diamétralement opposé (et je vois passer beaucoup de code où justement il y a les 2 pour cette seule raison).

Ce sont surtout 2 termes qui n'ont rien à voir, même si override implique virtual l'inverse n'est pas vrai. virtual ici n'est pas nécessaire, est redondant et contre-productif.
Si tu supprimes la fonction virtual de la classe mère et que la classe fille a la fonction déclarée virtual override, alors si les check d'override ne sont pas renforcés ta classe déclare maintenant une fonction virtual en plus/trop.
Si les checks sont renforcés, alors tu as une erreur de compilation error: ‘virtual ...’ marked ‘override’, but does not override sous gcc, error C3668: '...': method with override specifier 'override' did not override any base class methods sous VS2017. Erreur qui ne dépend que d'override et pas de virtual.

Donc au final, on se retrouve avec les modifiers de fonction (const, override, final) tous placés à droite dans la signature de la fonction. Et toi tu voudrais changer ça parce que... tu utilises mal virtual ? Vois des codebases où virtual est mal utilisé ?
L'exception ici serait plus virtual qu'autre chose. Encore que, il donne l'info d'utilisation/création de vtable. C'est plus qu'être un simple modifier d'utilisation, donc rien de choquant imo.

puisque c'est une bonne pratique de les mettre, pourquoi finalement ne pas les imposer?

On te l'a déjà répété une dizaine de fois mais tu sembles le refuser : rétro-compatibilité.
La philosophie C++ : tu payes pour ce que tu utilises uniquement.
Et tu es libre de te tirer une balle dans le pied en utilisant mal le langage. C'est ton problème.