Puzzled by this behavior

[Timon Gehr]

On 01.06.22 09:54, FeepingCreature wrote:
> On Tuesday, 31 May 2022 at 22:48:55 UTC, Don Allen wrote:
>> My concern is not "solving this". My concern is whether the language 
>> is clean and consistent so I can have mental model of it I can rely 
>> upon, rather than constantly searching through documentation to learn 
>> how a particular special case is handled. I also care a lot about 
>> writing readable code, and about being able to limit the visibility of 
>> variables to just the scope that needs them and no more. The 
>> workarounds you cite frankly feel like hacks to me, ugly ways of 
>> working around problems in the language design.
>>
>> /Don
>>
>>>
>>> -Steve
> 
> IMO this is completely internally consistent. Your mental model of a 
> function should be a tree of scopes; your mental model of a module 
> should be a lazily resolved key-value store. They're just fundamentally 
> different things.
> 
> You can make function scopes behave similar to global scopes, ie. void 
> delegate() foo; void bar() { foo(); } foo = { ... };, but then you just 
> move the compiletime error to runtime: ie. void delegate() foo; foo(); 
> You're basically manually implementing dynamic scoping. But D is 
> lexically scoped for functions, not just with nested functions but with 
> every language element. *Modules* are the exception - or rather, modules 
> are just a fundamentally different thing.

The simple fact is that the current behavior is less useful than what we 
could very easily have. There is no need at all to solve this with 
function pointers the way you describe, just allow forward references 
and overloading between local functions that are declared next to each 
other. All later stages of the compilation can very easily handle this, 
it's just a slightly different order of inserting stuff into scopes and 
analyzing it.