Gordon Vreugdenhil wrote: > Mark Hartoog wrote: > [...] > > My opinion is that engineers are not language experts, and giving an > > error when there is any ambiguity in what the default value expression > > means is ok. I would just like to point out that the other languages > > with this feature do not have things like hierarchical functional calls > > or interface function calls, which make this issue more complicated. > > > Mark, the problem with this approach is that we're defining > a *standard*. If you really want to permit ambiguity and room > for interpretation, fine, define the minimal required situations > in which something is guaranteed to have known behavior and > then add language for the remainder to the effect that "implementations > may choose....". Then it is clear to the users AND the implementors > what the base standard behavior is that one can rely on. That is not what I meant at all. Some knowledgeable people seem to expect default value expressions to be evaluated in caller context. Other knowledgeable people expect default value expressions to be evaluated in the function/task declaration context. Given this disagreement between knowledgeable people, we could simple vote and pick one by majority vote on the committee, or we could say that if it is not obvious to us, then it will not be obvious to users either, and change the *standard* to say that any case were these two interpretations might give different answers is illegal. Mark Hartoog 700 E. Middlefield Road Mountain View, CA 94043 650 584-5404 markh@synopsys.comReceived on Fri Mar 4 13:10:57 2005
This archive was generated by hypermail 2.1.8 : Fri Mar 04 2005 - 13:11:17 PST