Forward declaration

[ryuukk]

This code doesn't compile:

package sample api;

fn Main() -> i32 {
  return Square(12);
}

fn Square(x: i32) -> i32 {
  return x * x;
}

I think it is a huge mistake to mimic C/C++ to require forward declaration

It is time spent doing nothing, fighting with the language, time should be better spent working on solving the problems in my program

That's not an evolution to replicate the same mistake

[zygoloid]

See also previous discussion in #472 and proposal #875 which introduced the current rule.

[jaykrell]

I always thought that C and C++ were like this, in order to consume less memory on old machines.

Specifically, other languages like Modula-3, which are easier to parse into a complete per-module AST, keep more in memory and can make more passes.

i.e. forward declarations let you compile a function at a time, as you encounter them. An old and I think outdated constraint.

I don't think it was ever about readability. I think being like C or C++ here, is not doing humans a favor, it is just doing the huge machines of today the same favor that small machines needed.

[chandlerc]

I get that folks are surprised by this, but I think it would be useful to understand if there is any new information that they want to make sure is surfaced here that wasn't covered in the prior decisions that @zygoloid mentioned?

It's still fine to ask the leads to revisit this of course.

[pache-Ak]

There will be dependencies between modules. This relationship is not a simple linear relationship, but has a ring structure, which is actually a complex graph

Such dependencies cannot be fitted from top to bottom in the file, and even if we use forward declarations, the compiler still has to deal with such complex relationships.

It's hard for me to support inheritance from C++ unless there is solid evidence that forward declarations provide significant benefits.

We need modularity, and C++ needs modularity. So it's better to throw away these historical baggage.

[OlaFosheimGrostad]

The ability to adapt a tool to your needs is an important quality (as long as correctness isn't affected).

If programmers want to enforce things being declared before used as a policy then they can use a linter or a compiler-option. Transforming a library from one form to the other should be a trivial tooling task.

A tool should in general be flexible enough to support different existing practices at difference scales, if possible. What you want to do at a very large scale, might be very cumbersome at a medium or small scale.

Just look at Ada, it never gained traction because it only aimed at supporting very large scale projects. Also look at Chapel, interesting language, but with similar complications for more modest use cases.

(I see no critical technical arguments for having this limitation, beyond being slightly easier to implement.)

[zygoloid]

The current rules are designed to make it easy to revisit this question at a later point -- while we currently require forward-declarations, we also require the program to have the same meaning if order is ignored. We can reconsider this question at a later point, once the Carbon design is more complete and we have a better picture of what the costs and benefits of the alternatives here are. But we don't think now is the right time in the design process to do that, so for the time being we're going to continue to require forward declarations.