General comment.  I'm reminded of old Pascal, which had *reserved words*
and *standard words*, the former corresponding to C++ keywords, while
the latter could be freely redefined by the programmer (losing the built-in
meaning in the context of the redefinition).

Or if it wasn't Pascal then it was some other language in that family, e.g.
Modula-2  --  whatever.

Perhaps something like that distinction is needed for C++0x.




On 19 Sep 2002 09:23:09 -0400, Allan_W@my-dejanews.com (Allan W) wrote:

 >...
 >Getting back to your proposal, Alf, I have no problems with
 >either "succeed_or_throw" or "fallback_to" as keywords -- these short
 >phrases are unlikely candidates for good variable names.
 >
 >However, the name "succeed" is different. I think that there's a very
 >good chance that someone is using this as a variable name right now.
 >If it turns out that your proposal is accepted (in some form), the
 >word "succeed" would be a poor choice. I would nominate any of these:

 >    succeed_now

[+]
Much better than my suggestion, yes.

[?]
Or perhaps "succeed_by_continuing" and "succeed_by" (which would be
followed by a return-statement), instead of a single keyword "succeed".
It would bring the number of keywords, including "clean_up" (which
probably also needs adjustment!) to 5, and that's a more lucky number
than 4 or 3... ;-)


 >    code_succeeded

[-]
I think this may be used by current code, choosing names influenced by
the early idea of condition codes.


 >    fallback_not_needed

[-]
While true enough, it is an incidental issue that no further fallback
is needed  --  IMHO the wrong signal to give a reader of the code.



 >    succeed_after_throw

[-]
A succeed_or_throw must have at least one potentially reachable succeed,
for which there will usually not be any caught exception.


 >    succeed_or_throw_finished

[+]
Unlikely to conflict with existing code, expresses the right thing.

[-]
Not concise.  Devil's advocate: may be misread as "throw finished()".


 >    fallback_instead_of_rethrow

[-]
Expresses the wrong thing; succeed does not cause a fallback (it does
the opposite, succeeds instead of invoking the fallback code).


 >    std::succeed()

[+]
Unlikely to conflict with current code if that "std::" cannot be
implicit.

[-]
Rule about non-implicit "std" is inconsistent with current
qualification rules for namespaces.

[?]
Perhaps some other standardized namespace, e.g. as Glassbarrow, or was
it Potter, suggested, "kwd" (I'm not sure of the exact phrase).



 >I like some of these better than others, but I think that any of them
 >would be better than simply "succeed."

Yes, I think you do have a point, and it was nagging me.  Thanks.

Cheers,

- Alf

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]