Nested functions should be exempt from sequential visibility rules

[Michel Fortin]

On 2012-04-03 11:08:38 +0000, Don Clugston <dac at nospam.com> said:

> On 03/04/12 12:32, Timon Gehr wrote:
>> On 04/03/2012 10:27 AM, Don Clugston wrote:
>>> This is asking for a complicated special case. In global scope, order of
>>> declarations doesn't matter. In function scope, order of declarations
>>> always matters.
>>> If you have type inference of function returns, things can get nasty:
>>> 
>>> void foo()
>>> {
>>> auto b() { return a(); }
>>> X x = whatever;
>>> auto a() { return x; }
>>> }
>>> Now b actually depends on the declaration of x. So it's not enough to
>>> say that only function declarations are immune to ordering rules.
>> 
>> I come to a different conclusion. If only function declarations are
>> immune to ordering rules, the above example is simply illegal. The
>> example cannot be used to demonstrate incompleteness of the approach.
> 
> I don't see a way to just declare it as "illegal". How would you detect 
> that situation in the general case?
> It's not easy.
> 
> Y b() { ... }
> Y y = b();
> X x = ...
> 
> Prove that y doesn't depend on x.

You're right Don, it shouldn't be illegal. But it could be part of the 
constrain. Let's rephrase Timon's idea like this:

If two or more functions declarations are following each other with no 
other statement in between, then these two functions can call one 
another. That could allow overloading too, as long as the declarations 
are following each other directly.

In fact, that'd probably be generalizable to templates, struct, class, 
and enum declarations too. Adjacent declarations would create some kind 
of island in the function's code where order of declaration does not 
matter. The island ends at the first non-declaration statement or local 
variable declaration, and a new island begins when new declarations are 
encountered.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/