Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!caip!seismo!mcvax!ukc!dcl-cs!nott-cs!anw
From: anw@nott-cs.UUCP
Newsgroups: net.lang.c++
Subject: Re: Unintuitive semantics for initializing in for statements
Message-ID: <224@tuck.nott-cs.UUCP>
Date: Tue, 29-Apr-86 14:29:31 EDT
Article-I.D.: tuck.224
Posted: Tue Apr 29 14:29:31 1986
Date-Received: Sat, 3-May-86 01:46:02 EDT
References: <17195@rochester.ARPA> <5334@alice.uUCp> <101@cstvax.UUCP>
Reply-To: anw@nott-cs.UUCP (Dr A. N. Walker)
Organization: Maths Department, University of Nottingham, ENGLAND.
Lines: 27

In article <101@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:
> An alternative would be to have a 'for' expression - the same as a 'for'
> statement except that it returns the value of the iteration variable on
> exit.

	The trouble with all such suggestions is that there are too many
things that a loop *could* deliver, and for every application that would
make use of one such thing, there are equally worthy applications for all
the others.  Further, there is always a cogent objection.  For example,
you could return:

   a)	The value that the iteration variable would have on the next cycle
	[ie, the value that caused termination] -- but this could easily
	be > maxint.
   b)	The value it did have on the last cycle -- but there might not
	have been one.
   c)	The number of cycles -- but this could easily be > maxint [well,
	fairly easily].
   d)	Whatever the last obeyed controlled statement delivered -- but
	there might not have been one.
   e)	The collection of objects delivered by the controlled statements
	-- nice, but doesn't half fill up the stack!
   f,g,h,...)	Add to taste, depending on your favoured language.

	Better to have nothing than to spread such confusion!

							-- Andy Walker.