On 5/31/22 8:29 PM, Steven Schveighoffer wrote:

Oh my, I just realized, a function prototype that's later defined could end up using stack frame data that doesn't exist. This is the reason for not allowing prototypes or forward reference functions:

void foo()
{
  void bar();
  bar(); // would affect x before it exists
  int x = 5;
  void bar() { ++x; }
}

So just use a static struct if you want mutual recursion.

-Steve

On 5/31/22 9:20 PM, Timon Gehr wrote:

Sorry, I meant struct static functions. A static struct is OK if you just want recursive behavior, but don't need to access the stack frame. You can also use normal member functions inside a normal struct if you do need the stack frame.

I use it when I need to implement algorithms that are recursive, but I want to separate out the pieces to multiple functions.

-Steve

On Tuesday, 31 May 2022 at 22:48:55 UTC, Don Allen wrote:

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.

On Wednesday, 1 June 2022 at 07:54:04 UTC, FeepingCreature wrote:

The functions foo and bar are in the same scope, checking for initialization before use is not strictly related. Also goto can jump to a forward label, so C allows some forward references.

On Wednesday, 1 June 2022 at 08:22:24 UTC, Ola Fosheim Gr wrote:

Well, I guess you can say that every new name creates a new scope as it shadows the outer scope in order. Anyway, a prototype isn't a bad trade-off.

(Btw IIRC «dynamic scope» is a completely different concept, that means the lookup is done down the call-graph. E.g. if function f() calls g() and f() has xthen g() will access f()'s x when mentioning x.)

On Wednesday, 1 June 2022 at 07:54:04 UTC, FeepingCreature wrote:

I don't disagree with your description of D -- that module-level scopes are different than those at function level. You omitted struct-level scoping, which is similar to how modules are handled. And your discussion of how to make function-level scoping behave like module-level scoping ignores what I have previously written. I know of the availability of these workarounds and to me they are just band-aids on an odd language inconsistency.

I will say this once more and I'm done: function-level scoping in D is different from the other two D cases and different from other prominent lexically scoped languages. I question why that is. You assert that things are "internally" consistent. That may be so, but I would argue that that is completely irrelevant. What matters is external consistency, what the programmer sees.

On Wednesday, 1 June 2022 at 13:48:48 UTC, Timon Gehr wrote:

The most sensible is to let local functions be syntax sugar for lambdas. Just make delegate variables assign-once and initialize-before-use.

The core D semantics can be made quite simple with a bit of effort. I hope SDC thinks about how to boil the D semantics down to a bare minimum…

On Tuesday, 31 May 2022 at 22:48:55 UTC, Don Allen wrote:

While I agree that sometime, D takes the road of many special cases, if you take a step back, you'll that this really doesn't help your case, to the contrary. You are arguing for special casing function scope to allow out of order symbol resolution in special circumstances.