> Sounds like what everything needs is a differently named enum: say > three_way_logic.
Well, one might just rename the present enum 'match' (which anyway lacks the usual 'gfc' prefix), to something like 'gfc_three_way_logic' (or whatever name you prefer), with appropriately named values. Then one could apply it in a more general setting without causing confusion. But that would be a *huge* patch (though completely mechanical), and I'm not sure if I would be willing to waste my time writing a ChangeLog for that (unless there is an automated way for this by now?!?). Cheers, Janus > On Nov 3, 2011, at 3:56 PM, Janus Weil wrote: > >>> At least add a comment about the re-use (abuse?) of the >>> enum. >> >> Updated patch attached, which adds a short comment on the usage of 'match'. >> >> >>> This should reduce confusion months from when >>> someone wonders why gfc_extend_expr returns a "match" >>> for a non-matching function. >> >> Well, I think my approach is not as far-fetched as you seem to imply: >> There are already a good number of procedures which use the 'match' >> enum, although they're not related to matching at all. Listing only >> those that occur in gfortran.h (I'm sure there are more): >> >> * match gfc_mod_pointee_as (gfc_array_spec *); >> * match gfc_intrinsic_func_interface (gfc_expr *, int); >> * match gfc_intrinsic_sub_interface (gfc_code *, int); >> * match gfc_iso_c_sub_interface(gfc_code *, gfc_symbol *); >> >> The reason for this is of course that the YES/NO/ERROR triple is not >> only useful in matching, but also in many other situations. >> >> Cheers, >> Janus >> <gfc_extend_expr_v2.diff> > >
