From maine@altair.dfrc.nasa.gov Thu Jan 25 22:36:45 1996 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id WAA14410 for ; Thu, 25 Jan 1996 22:36:41 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA11447; Thu, 25 Jan 1996 13:36:38 +0800 Date: Thu, 25 Jan 1996 13:36:38 +0800 Message-Id: <9601252136.AA11447@altair.dfrc.nasa.gov> From: Richard Maine To: wwalter@math.tu-dresden.de Cc: SC22WG5@dkuug.dk In-Reply-To: <199601251855.TAA09296@dkuug.dk> (wwalter@math.tu-dresden.de) Subject: Re: (SC22WG5.1013) Problems with initialization content-length: 1605 Wolfgang said:> > does anyone know why the initialization of a function result at the > point of its type declaration is currently prohibited? We have > stumbled across this problem and do not understand why the function > result cannot simply be treated like any other local variable. > The constraint that implies the SAVE attribute for initialized > objects seems a pretty meek excuse. I'd say that you answered the question yourself, except that I'd call the implied SAVE attribute very pertinent. In particular, note that the implementation of initialization for a function result would have to be completely different from most (all?) implementations of local variable initialization. Local variable initialization is typically done by allocating a static address and initializing it at load time. The standard doesn't require it to be implemented that way, but that is how most if not all implementations do it. Such an implementation wouldn't work for initializing a function result. Initialization of a function result would have to be done at each invocation of the function (and would thus be pretty indistinguishable from just doing it as the first executable statement of the function - just a syntax difference). I can't off-hand think of anything else in f90 that is comparable. F95 has default initialization, which acts like this (in fact default initialization applies to function results, if I recall correctly), but f90 has nothing. Thus, this would have been more than just an obvious extension of other f90 syntax. -- Richard Maine maine@altair.dfrc.nasa.gov