Compile-Time Const

Topics: Language Specification
May 3, 2013 at 2:18 AM
I read up on a suggestion to add the const keyword (similar to C++ const) to the language, and the main reason it was declined was because it would require too much code injection to make const work in javascript (plus there was no way to make 100% sure that it wouldn't be overridden).

I was wondering if it would be a good idea to add a compile-time const that compiles away similar to the interface keyword/structure?

This way it would be easy to tell if class functions were read-only, if variables didn't get altered by a function and to create "pseudo const" values (which can't be edited in typescript using the "." accessor).

If the last one is too much hassle, the first two would be awesome!

Consider the following code:
class ShaderMaker {
    ....
    const compileShaderCode (): compiledshader { ... }
    ....
}
The user would be sure that by calling compileShaderCode the ShaderMaker object will not be modified.

It would also be good to understand how the overloads of certain functions work, for example, jquery's offset():
interface JQuery {
    ...
    const offset(): { top: number; left: number; };
    offset(const coordinates: any): JQuery;
    offset(func: (index: any, coords: any) => any): JQuery;
    ...
}
...
$("mydiv").offset( // -> intellisense now shows that offset() is const, and will not modify the div.
Also, with the second definition for offset, the coordinates are now declared with a const, which means that the user can be sure that the object will not be modified by the function.
May 9, 2013 at 3:25 AM
Did anybody actually read this?
Did I put it in the wrong place?

It's weird going to the effort to post something and not getting any response a week later O.o.
May 9, 2013 at 10:26 AM
@Griffork,

I didn't comment on the discussion because:

(a). There was bound to be someone along from TypeScript with the response "We are at present working on aligning TypeScript to ECMAScript 6. Please feel free to vote on other issues that you would like to see supported so that we can prioritise them".

(b). My personal response to const methods is: "meh". It will be nice to indicate to users of your API which methods are likely to to mutate your object, but then do they really need to know that? It is a kind of a fine-grained information that is borderline a bit too excessive.

My preference is to be able to mark entire classes as immutable, for example
immutable class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}

var greeter = new Greeter("world");

greeter.greeting = "Hello, hacker"; // Error Class Greeter is immutable
This can also be enforced at runtime via Object.freeze(...).

This seemed slightly off-topic to your suggestion.
Coordinator
May 9, 2013 at 2:07 PM
@nabog - I see what you did there :)

We experimented with a 'readonly' property a while back. My memory is a little fuzzy, but I believe the issue was that if you introduce 'readonly', where all does it go? At first you put it on 'const' style things, and if you put it there, then you'll want to be able to annotate function parameters with it, and to do that would introduce it into the type system. I think the issue was that once it's a part of the type system, it has to play well with type inference and common JS patterns, but as we start writing out examples of how it would work in practice, and the code felt less and less like JavaScript and more like some new language. In general, we've tried to keep TypeScript feeling just like a lightweight annotation to JavaScript that helps you catch errors, and give you good tooling, but otherwise doesn't get in the way.
May 10, 2013 at 12:22 AM
Isn't const a part of the ECMAScript 6 spec already? From what I've read, FireFox and chrome already support the use of the const keyword and there is partial support in Safari and Opera. From the MDN (https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Values,_variables,_and_literals#Constants):
const a = 7;
console.log("a is " + a + ".");
// THIS WILL CAUSE AN ERROR
function f() {};
const f = 5;
 
// THIS WILL CAUSE AN ERROR ALSO
function f() {
  const g = 5;
  var g;
 
  //statements
}
May 10, 2013 at 3:15 AM
Edited May 10, 2013 at 3:20 AM
True, I just read over the draft, and it seems that it was added in ECMAScript 6 rev 3 and hasn't really been disputed since:
Draft Specification for ES.next (Ecma-262 Edition 6)

Although, after hearing your point @jonturner I can understand wanting to put off support for const until it's adopted widely if it's hard to implement, however It is supported in Mozilla and Chrome (v8), Safari and Opera will accept const declarations but don't enforce them.

Also, thank you very much for the replies :). I didn't want to whinge, but sometimes a "no" is better than not hearing anything.
Coordinator
May 10, 2013 at 2:08 PM
@dflor003 and @Griffork

There's a good chance that if it gets into ES6 that TS will adopt it (though likely after 1.0). We just would have to work out how it affects the type system, or if it's just a way of making a "simple" constant where we verify that it's never assigned to and call that enough.
May 10, 2013 at 2:36 PM
jonturner wrote:
In general, we've tried to keep TypeScript feeling just like a lightweight annotation to JavaScript that helps you catch errors, and give you good tooling, but otherwise doesn't get in the way.
You guys have done a rather good job of doing exactly that. Great work with the generics as well.

@dflor003, I don't believe the ECMAScript const extends to const methods.
Aug 30, 2013 at 12:43 PM
I just opened a request for const support referencing some comments posted in this thread.