suggestion to inline const keywords for ES5

[Gambero81]

it would be great to transpile const declaration with inline value when target is ES5 (as already Done with const enum), so it will prevent to include useless javascript.
An example:

const A = "myConstValue";
alert(A);
// generated js code:
alert("myConstValue" /* A */)

Another example:
module MyConstMudule
{
   export const A = "myConstValue";
}
alert(MyConstModule.A);
// generate js code:
alert("myConstValue" /* MyConstModule.A */);

what do you think?

[mhegazy]

How does it get emitted in a .d.ts for instance? what if the const value is dependent on non-const values or has side effects, e.g.

declare function foo():number;

const x = foo();

console.log("here is x: " + x);
console.log("again: " + x);

the const enums are restricted to only constant expressions which is different from the const semantics; so we can not copy the implementation, we need to come up with a different proposal.

[dead-claudia]

Suggestion: limit that scope to what enums can handle. And FWIW, in my enum proposal, I already created an algorithm to figure out most of what's safe to replace. It's intentionally limited to booleans, numbers, strings, null, and undefined, and function calls do not count. It's towards the end of this section.

As for functions themselves, there's a lot of bikeshedding to do to figure out how, if possible, to judge and/or enforce if a function is truly immutable or not.

If functions are explicitly designated as immutable, it's not hard to verify those functions as immutable. And for languages that are immutable by default, it's even easier. Inferring if a function is mutable is easy - it's a matter of "Is there any way this can cause side effects?". Merely an assignment to a reference the function didn't create is enough to say yes (variable outside a closure, assignment to member, etc.).

As for inferring immutability, that's probably impossible to do completely. Even in C/C++, as advanced as their compilers are, they still can only partially make that judgement, even with the static types and explicit reference vs value, and even without lexical closures (in the case of C). This is still a CS research topic in trying to figure how far they can. As for why it's likely impossible to fully infer this, try to factor in branch checking or recursion (which requires branch checking) into the process. It would require partially running the program to figure some parts out. You'd have to build a Turing-complete scope checker to figure that out.

[mhegazy]

This is then just constant propagation. it is not strictly tied to const declarations or enums. we will have to allow constant expressions to emitted in .d.ts files (which today they do not) to enable this feature.

[dead-claudia]

@mhegazy I'm aware of that. That's basically what the suggestion would entail, just as the enum situation currently does. I am fairly neutral on this, although IMHO it would be better for the compiler to allow some sort of pluggable transform like what Babel does, or a similar framework to allow that. The API exists to do the manipulations, but there isn't much of an ecosystem to go with it.

[TazmanianDI]

This seems like something that could benefit styled components which use template literals for building CSS. If this change supported template literals that would be great.

For example:

const VALUE = 10;
const aString = `A ${VALUE} B`;

Could be output as (although this might break tagged template literals).

const aString = `A ` + 10 + ` B`;

Or potentially just

const aString = `A 10 B`;

[dead-claudia]

@TazmanianDI This is unsafe for three scenarios:

1. Symbols (they are not coercible)
2. Reference types (.toString is called)
3. Tagged template literals (as you already mentioned)

In all other use cases, this is a safe thing to do. Conveniently, constant propagation works only for literals, and all literals except objects and functions are primitives, so the only problematic construct would be with tagged template literals.

Note that this could increase code size, and so it should be disabled by default.

[G-Rath]

I might be missing the point here a little, but why not just use the same syntax with enums: const type?

This is what I'm trying to do:

// index.d.ts
export declare namespace API {
    namespace ListUsers {
        const type ENDPOINT = '/users';
        const type METHOD = 'GET';
    }
}

// api.ts
const listUsers = () => Axios.request({
    baseUrl: process.env.API_BASE_URL,
    method: API.ListUsers.METHOD,
    url: API.ListUsers.ENDPOINT
}).then(response => response.data);

I can do this just fine with const enum, but I'd not like to make single-value enums.
Let me know if this is actually a separate feature request 😄