Suggestion: disallow use before definition

[RyanCavanaugh]

The compiler should issue an error when code uses values before they could possibly be initialized.

// Error, 'Derived' declaration must be after 'Base'
class Derived extends Base { }
class Base { }

[everson]

While throwing a compiler error is a good solution, perhaps the compiler could output the classes in the right order. That would be a killer feature. E.g. The compiler keeps track of dependency relationship and output the classes according to that, throwing the compiler error only when unable to resolve the dependency order.

[jvilk]

The compiler keeps track of dependency relationship and output the classes according to that, throwing the compiler error only when unable to resolve the dependency order.

Should we make this a new suggestion? This is why I currently use AMD modules rather than TypeScript internal modules; the RequireJS compiler determines the appropriate module serialization order using the dependencies I specify across the codebase (using require()).

[RyanCavanaugh]

Linking to #274. We need to outline what the rules and scope of this would be

[mhegazy]

The extends case seems like a good candidate for lexical checking; we just need to ensure that lexically the base class comes before the derived one. Are there other cases that we should consider?

[sparecycles]

One issue is that reordering class definitions might reorder the static initializer order silently. If the base class comes after a derived class I vote to either maintain the static initializer code at the class definition site or just flag an error.

I think that the multiple file case is more interesting and useful from a large project / maintenance standpoint (which is the ostensible goal of typescript, after all).

So, I think we need to consider the output order in single-file output mode. (it would also be nice to be able to get this order for building html files which include multiple files).

Here are some statements that I think would ensure ordering:

class X extends Y {} // ensure Y is defined in prior file
module { new X(); } // ensure X is defined in prior file
class S { static z = new Z(); } // ensure Z is defined in prior file

We could also extend this to functions and variables being defined before use, not just classes.

P.S. I have a prototype.

[danquirk]

I don't think there is any intention to attempt to reorder emit for you, only to give errors where we can for things that are sure to fail at runtime.

[sparecycles]

Dan, I agree with you about reordering within a single file, but when multiple files are combined using --out, the compiler has control over the emit order and I'd prefer that the order it chooses, works.

[mhegazy]

@sparecycles functions are hoisted to the top of the scope anyways at run time. so functions are not interesting. variables are hoisted as well, the issue is that they will not be initialized at that point. now use before initialization is a different issue, and I think it is tracked under #274.

for reordering; the philosophy we have followed, is to let the output code be as close as possible to the input code. in essence we let the user code pass through, we just strip out types. in this sense, an error would be more inline with what we have done thus far.

As for the implementation, I have added a lexical order verification recently with Let and Const, and can be extracted out as a general check and used for these different cases. you can find it here:
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L329

We need to clearly identify the cases where we are checking, and a PR would be definitely welcomed :)

[sparecycles]

Yes, I agree that we don't want to reorder within a single typescript file, but in the --out file case, the order is not specified by the user so, again, I would prefer that the compiler makes a best effort to choose an order that works.

The function hoisting is a good example of where we don't need to care in the single file case, but where compiling to multiple files and choosing a sequence to include them in an .html file can be non-trivial for a human. Variables being undefined at use is a great example of where unexpected behavior can be introduced by the compiler because of a change in /// <reference> lines.

[RyanCavanaugh]

but in the --out file case, the order is not specified by the user

This isn't really the case. We have very simple rules here -- use the order implied by the reference tags and the order of files on the command-line. In both cases, the user is providing us an order. Having the compiler ignore the ordering that the user provided is a dangerous route to go down. What if the compiler decides an order different from the one you'd prefer? How would you override that? What if one order breaks 2 classes and another order breaks 2 variables?

[sparecycles]

Then we shouldn't change the order but should we at least (have the option to) warn the user that the order the compiler uses is probably wrong?