函数和结构体的前置什么是否必须?

[zhangzhimin]

我们围绕函数来讨论, 首先先描述下什么是前置声明,
func test(); 类似于C++, 函数只有声明, 没有实现我们称之为前置声明.

现在我们支持函数的递归.

func test() {
      test(); // 调用自己
}

是否还存在必须需要前置申明才能处理的逻辑. 没有前置申明我们支持不了下面的形式

func test2();

func test1(){
      test2();
}

func test2(){
     test1();
}

上述的形式是必须的吗? 函数前置声明还能带来其他好处吗?

[microctar]

Wikipedia: Forward declaration

In computer programming, a forward declaration is a declaration of an identifier (denoting an entity such as a type, a variable, a constant, or a function) for which the programmer has not yet given a complete definition.

---

Wikipeida: Function prototype

In computer programming, a function prototype or function interface is a declaration of a function that specifies the function’s name and type signature (arity, data types of parameters, and return type), but omits the function body. While a function definition specifies how the function does what it does (the "implementation"), a function prototype merely specifies its interface, i.e. what data types go in and come out of it. The term "function prototype" is particularly used in the context of the programming languages C and C++ where placing forward declarations of functions in header files allows for splitting a program into translation units, i.e. into parts that a compiler can separately translate into object files, to be combined by a linker into an executable or a library.

In a prototype, parameter names are optional (and in C/C++ have function prototype scope, meaning their scope ends at the end of the prototype), however, the type is necessary along with all modifiers (e.g. if it is a pointer or a reference to const parameter) except const alone.

In object-oriented programming, interfaces and abstract methods serve much the same purpose.

[microctar]

有关于前置声明的讨论，可见于Google开发的新语言 -- Carbon的issues版块下的讨论:
carbon-language/carbon-lang/issues/1416

---

亦可见于nim-lang:
nim-lang/Nim/issues/5287

[haobosang]

Forward declaration：是在编程语言中提前声明一个函数或类的存在，但不提供其实现。这样可以在函数或类的定义出现之前使用它。
好处：：加快编译速度。编译器首先会做一次函数解析,如果有很多函数互相调用,没有前置声明会造成大量的跳转和回跳,影响编译效率。

[microctar]

the-joys-of-forward-declarations-results-from-the-real-world

I also had a bit of a hint that our header dependencies were a little bloated when I found that Visual Studio’s built-in dependency graph generator consistently crashed when I tried to run it on our code base. Still, I didn’t have any real proof that forward declarations would actually improve anything at all. Just an intuition. So we decided to be Agile about it.

I took the top 5-10 headers that were most often included, and I made it a challenge to replace them with forward declarations wherever I could. If doing this improved things at all, then I could go ahead and take a more comprehensive approach.

What we found was that we could do a full rebuild of our C++ 10% faster! Along the way I gained even more confidence that a more comprehensive approach would yield additional gains.

[zhangzhimin]

这个是一个因素, 对于C++来说其会包含文件去编译. 不过这个原因在Prajna里并不存在, 因为Prajna里不会去包含所需的文件, 其会直接用编译好的Prajna IR.

[microctar]

以下引自讨论原文

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

carbon-language/carbon-lang#1416 (comment)

---

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.

Originally posted by @jaykrell in carbon-language/carbon-lang#1416 (comment)

---

I think the more full details / rationale and such should be up-coming in #875 which aims to capture this decision in a principle.

That said, here is a summary from my memory of the discussion that I ran past the other leads and so I think it is roughly accurate if somewhat brief:

The leads felt like the tradeoffs ended up borderline. We specifically walked through the Carbon priorities to look for tradeoffs on each one.

Many cases would have a different thing be made easier, but without any clear indication that one was more important than another. For example readability is a priority for Carbon. We know that some readers will prefer a "top-down" structure, but others will prefer to not have to scroll past helper code to find interesting code. It isn't clear that one or the other is significantly more important to optimize for, and neither seemed to be severe problems.

Two somewhat minor points were language evolution and migration from C++. The top-down model is expected to be easier to relax into the other if desired compared to the other direction. And the top-down model may minorly reduce the initial surprise of C++ programmers encountering Carbon code as it will follow a fairly similar structure.

Or the leads could decide these minor differences aren't big enough to really make a decision, and just let the painter pick a bikeshed color. The painter confirmed the color would be "top down" because it would match the paint of C++.

Either way, we end up in the same place.

Originally posted by @chandlerc in carbon-language/carbon-lang#472 (comment)

[zhangzhimin]

般若也编译不了类似的代码. 要使用未声明的Square, 隐藏着前置声明的功能, 只是C#等可能是由编译器完成的. 我说的不支持前置申明, 也包含了不知道上述的代码编译.

[microctar]

如何免去前置声明的麻烦:

Wikipedia: Multi-pass compiler

A multi-pass compiler is a type of compiler that processes the source code or abstract syntax tree of a program several times. This is in contrast to a one-pass compiler, which traverses the program only once. Each pass takes the result of the previous pass as the input, and creates an intermediate output. In this way, the (intermediate) code is improved pass by pass, until the final pass produces the final code.

Multi-pass compilers are sometimes called wide compilers,[citation needed] referring to the greater scope of the passes: they can "see" the entire program being compiled, instead of just a small portion of it. The wider scope thus available to these compilers allows better code generation (e.g. smaller code size, faster code) compared to the output of one-pass compilers, at the cost of higher compiler time and memory consumption. In addition, some languages cannot be compiled in a single pass, as a result of their design.

Advantages of multi-pass compilers

Machine Independent: Since the multiple passes include a modular structure, and the code generation decoupled from the other steps of the compiler, the passes can be reused for different hardware/machines.

More Expressive Languages: Multiple passes obviate the need for forward declarations, allowing mutual recursion to be implemented elegantly. The prime examples of languages requiring forward declarations due to the requirement of being compilable in a single pass include C and Pascal, whereas Java does not have forward declarations.

[microctar]

以下内容来自于Principle: information accumulation:

Single-pass "splat" compilation (L58 - L87)

In C and other languages of a similar age, single-pass compilation was highly
desirable, due to resource limits and performance concerns. In these languages:

• Information is accumulated top-down, and can only be used lexically after it
  appears.
• Most information can be discarded soon after it is provided: function bodies
  don't need to be kept around once they've been converted to the output
  format, and no information on local variable or parameter names needs to
  persist past the end of the variable's scope. However, the types of globals
  and the contents of type definitions must be retained.
• The behavior of an entity can be different at different places in the same
  source file. An early use may fail if it depends on information that's
  provided later, and in some cases a later use may fail when an earlier use
  succeeded because the use is invalid in a way that was not visible at the
  point of an earlier use.

Global consistency

In more modern languages such as C#, Rust, Java, and Swift, there is no lexical
information ordering. In these languages:

• Information is effectively accumulated and processed in separate passes.
• The language design and implementation ensure that the behavior of an entity
  is the same everywhere: both before its definition, after its definition,
  within its definition, and in any other source file in which it was made
  visible.
• Dependency cycles between program properties are carefully avoided by the
  language designers.

---

Separate declarations and definitions (L122-L127) & (L138-L140)

One key benefit of this separation is in reduction of physical dependencies:
in order to validate a usage of an entity, we need only see a source file
containing a declaration of that entity, and need never consider the source file
containing its definition. This both reduces the number of steps required for an
incremental rebuild and reduces the input information and processing required
for each individual step.

Another key benefit is that the exported interface of a source file can become
more readable, by presenting an interface that contains only the facts that are
salient to a user and not the implementation details.

[microctar]

在过往，前置声明算是出于对资源和性能考量。
如今，在更现代的编程语言中，以rust、java、C#等为例，舍弃了这种做法。
参考了部分资料以后，我个人认为，可以出于可读性等需求，保留前置声明；也可以根据开发者的使用经验，舍弃前置声明。
这是可选的。

[microctar]

我们围绕函数来讨论, 首先先描述下什么是前置声明, func test(); 类似于C++, 函数只有声明, 没有实现我们称之为前置声明.

现在我们支持函数的递归.

func test() {
      test(); // 调用自己
}

是否还存在必须需要前置申明才能处理的逻辑. 没有前置申明我们支持不了下面的形式

func test2();

func test1(){
      test2();
}

func test2(){
     test1();
}

上述的形式是必须的吗? 函数前置声明还能带来其他好处吗?

C++ 是混合的规则。
函数前置声明适用于free functions， 而类的成员函数并非如此。

出自于Principle: information accumulation第89至106行。

The C++ compromise

In C++, a hybrid approach is taken. There is a C-like lexical information
ordering rule, but this rule is subverted within classes by -- effectively --
reordering certain parts of a class that appear within the class definition so
that they are processed after the class definition. This primarily applies to
the bodies of member functions. Here:

• Information is mostly accumulated top-down, and is accumulated fully
  top-down after the reordering step.
• The behavior of a class is the same within member function bodies that are
  defined inside the class as it is within member function bodies defined
  lexically after the class.
• The language designers need to ensure that the bounds of the member function
  bodies and similar constructs can be determined without parsing them, so
  that the late-parsed portions can be separated from the early-parsed
  portions. In C++, this was not done successfully, and there are constructs
  for which this determination is very hard or impossible.

[zhangzhimin]

struct Tmp {
    b : i64;
}

implement Tmp {
    func test() {
        test2();  // compiler error, undefined test2
    }

    func test2 { test(); }
}

目前般若的类成员函数必须在它前面的才能引用, 因为这和我们的前置声明有一定关系. 如果不支持前置声明, 要实现成员函数的相互引用是比较困难的.
"只能引用已经定义过的成员函数"这种情况有什么弊端吗?

[zhangzhimin]

后面可以持续关注, 目前来说至少 "前置声明优先级是不高的", 考虑到实现难度, 就先不支持了.