Path: utzoo!mnetor!uunet!husc6!cca!g-rh From: g-rh@cca.CCA.COM (Richard Harter) Newsgroups: comp.lang.c Subject: Re: The D Programming Language Message-ID: <25203@cca.CCA.COM> Date: 3 Mar 88 05:34:28 GMT References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> <2327@umd5.umd.edu> <2731@mmintl.UUCP> <24935@cca.CCA.COM> <2736@mmintl.UUCP> Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter) Organization: Computer Corp. of America, Cambridge, MA Lines: 43 Summary: Resolving dangling else's In article <2736@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <24935@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: || if (boolean expression) || .... || end || else || .... || end | |Note that this does *not* solve the dangling else problem. That being the |case, I see no reason to prefer it to the current syntax. I wasn't suggesting it as a resolution of the dangling else problem, because, as you note, it isn't whether or not one has labels. It struck me as an idea that might have some value -- and it might if the compiler pro- duced a listing that labelled each line with the block that was part of. I am now persuaded that the idea has no particular merit. If one is really concerned about the dangling else problem there is a very simple solution -- use different keywords for two sided if's and one sided if's. For example, the presence of a 'then' keyword guarantees an 'else' and its absence guarantees the lack of an 'else'. E.g. if (e1) then if (e2) A; else B; <---- this pairs with the first if if (e1) if (e2) then A; else B; <---- this pairs with the second if if (e1) if (e2) A; else B; <---- this is a syntax error Another cure is to always require that an 'else' statement be present, even it if it is null. Personally, I am inclined to feel that all of the cures (including endif) are worse than the disease. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.