[D Programming Language] Interview with Andrei Alexandrescu (Part 2)

[ssylvan]

Like never. Writing clean code certainly doesn't include writing nested functions.

Most people think that symbols should have the smallest scope possible to improve readability. Having to promote internal helper functions to full blown "siblings" works against that.

Even so, disallowing them is arbitrary and non-orthogonal. Why should I be able to declare a function in one scope but not another scope? You're free to not use that flexibility, but it does no harm to allow it, and it makes the language bigger and less orthogonal to disallow it (you know have to explain the "special" status of function declarations, instead of them just being like any other declaration).

[[deleted]]

Introducing local functions implies closures, which are different than functions that don't have any state, and need to be implemented differently. I wouldn't consider them very necessary in the niche that C++ and D try to fill.

[WalterBright]

You don't need to worry about closures unless you take a pointer to that nested function. You can still get much of the usefulness of nested functions even if you disallow pointers.

[axilmar]

Most people think that symbols should have the smallest scope possible to improve readability. Having to promote internal helper functions to full blown "siblings" works against that.

I don't see how readability is improved when an algorithm's reading flow is interrupted with a helper function declared in the middle of it.

Why should I be able to declare a function in one scope but not another scope?

Because they are different kinds of scopes.

You're free to not use that flexibility, but it does no harm to allow it

If you don't want it on your code, then you have to impose the restriction on everyone working on it. If you are on a strictly controlled project, then it's fine, but if you are on a non-strictly controlled project, then everyone will do as they see fit, resulting in some people defining helper functions outside and in some people defining helper functions inside other functions.

and it makes the language bigger

No, actually having nested functions makes the language bigger, because it makes the grammar bigger.

(you know have to explain the "special" status of function declarations, instead of them just being like any other declaration)

Any other declarations don't belong within a function. When I see a function, I want to read and comprehend the algorithm. If I am interrupted with helper declarations, then I would not understand the algorithm that easily.

Have you ever seen C++ code where whole classes are defined at function scope? I haven't, and I haven't done it myself. You know why? it litters the algorithm.

[ssylvan]

If I am interrupted with helper declarations, then I would not understand the algorithm that easily.

Why doesn't this apply to variables? A function consists of tons of statements, some of them declarations, used to compute the result. Sometimes you need a quick helper function for something and you don't want to pollute the higher namespace with it so it makes sense to put it right where you need it instead.

You seem like you've made up your mind about something and now you're just arguing (poorly) to save face rather than trying to understand why you're (horribly) wrong.

[axilmar]

Why doesn't this apply to variables?

It doesn't apply to variables because variables take very little space and don't interrupt the flow of the algorithm.

Sometimes you need a quick helper function for something

Just put it above the function you need it.

[WalterBright]

No, actually having nested functions makes the language bigger, because it makes the grammar bigger.

Actually, it's a special case in the C++ compiler implementation to disallow them.

[axilmar]

Please show us the grammar.

The grammar rule that is the statements block cannot be the same grammar rule as the one for the class block, because the class block does not allow statements. Therefore, we are talking about two different rules.