1. 19

  2. 9

    While I really love the overall message of this post – that it is usually most useful when discussing language features to drop the word “explicit” in favor of more precise words that capture specific aspects of “explicitness” – I’m not sure I agree with the idea that the definition of “explicit” presented in the article can ever be useful at all. In particular, according to the article, “explicit is not local,” which seems to propose that “explicit” be shorthand for “deducible about a program from global analysis of its source code.” If this is the definition being proposed here, then I’m not sure I understand how any feature could ever be “implicit.” In principle every property of a program (that can be known at all) can be known by looking at its source code; after all, the source code is the program!

    I find myself wondering: what kind of properties of a program would not be explicit under this definition, except for properties that are unknowable either in theory because of decidability issues, or in practice because they are only determined by complicated and unpredictable runtime behavior? And if properties not amenable to static analysis are the only “implicit” properties, then doesn’t “explicit/implicit” become a synonym for “static/dynamic”? If so, why not just talk about “static/dynamic” instead?

    1. 4

      I sometimes thought it would be cool if not destroying a resource were a compiler error, but you still had to manually call the right function to do the cleanup. Might be painful to type, but would be pretty explicit :)

      1. 11

        What you ask for is full linear types. There’s a couple of problems here, for example, Rust has the notion of panicking. How do you deal with the stack unwinding past such a type?

        Also, for most plain data types, this is not very interesting, which the vast majority are.

        Optionally allowing such types in Rust is often called for, but harder in practice then it seems, especially due to non trivial, especially very pervasive relationships. For example, if you have a type Linear, Option<Linear> has to be, too.

        There’ a good writeup here:


      2. 1

        Explicit is better than implicit, unless the implicit is simple and predictable or not something you need to worry about.