On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote: > On 1 December 2015 at 16:01, Steve Kargl > <s...@troutmask.apl.washington.edu> wrote: > > On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote: > >> > >> David Malcolm nice Levenshtein distance spelling check helpers > >> were used in some parts of other frontends. This proposed patch adds > >> some spelling corrections to the fortran frontend. > > > What problem are you trying to solve here? The patch looks like > > The idea is to improve the programmer experience when writing code. > See the testcases enclosed in the patch. I consider this a feature :)
Opinions differ. I consider it unnecessary bloat. > > unneeded complexity with the result of injecting C++ idioms into > > the Fortran FE. > > What C++ idioms are you referring to? The autovec? > AFAIU the light use of C++ in GCC is deemed OK. I see usage of > std::swap and std::map in the FE, not to mention the wide-int uses > (wi::). Thus we don't have to realloc/strcat but can use vectors to > the same effect, just as other frontends, including the C frontend, > do. > I take it you remember that we had to change all "try" to something > C++ friendly. If the Fortran FE meant to opt-out of being compiled > with a C++ compiler in the first place, why were all the C++ clashes > rewritten, back then? :) Yes, I know there are other C++ (mis)features within the Fortran FE especially in the trans-*.c files. Those are accepted (by some) as necessary evils to interface with the ME. Your patch injects C++ into otherwise perfectly fine C code, which makes it more difficult for those with no or very limited C++ knowledge to maintain the gfortran. There are currently 806 open bug reports for gfortran. AFAIK, your patch does not address any of those bug reports. The continued push to inject C++ into the Fortran FE will have the (un)intentional consequence of forcing at least one active gfortran contributor to stop. -- Steve
