What if $ was used to mark variable types instead of :?
Then we could inspect code compiled with types like:
var typedVariable$string = "Hello and welcome to my idea thread. Nice to meet everyone here."
That’s already valid in identifiers.
1 Like
Isn't that a good thing?
No, it means that it's not possible to change the semantics of a variable based on what is after a $ in the name.
2 Likes
You mean the Type is immutable? When saved like This$Type?
Edit: Oh I am talking about compiled JS.
There is no "compiled JS" in the way that you mean; all JS at runtime is the same, and $ is a valid character in identifiers, and as such it can never mean anything different.
2 Likes
My original post was to discuss the JavaScript typed comment standard.
I am not sure what context you are referring to. When I say "compiled JS" I mean code either written by humans or compiled with type information.
A valid identifier is a valid tool for Type analysis.
There is existing code that will have a $ in the middle of the identifier name, and that code can't suddenly mean "a type". Additionally, that wouldn't support typing property or function names.
1 Like
I'm thinking about it from the JS side. I see what you mean from the TS side but the compiler can just append another $Type to the end. The JS code doesn't know the difference.
Is the problem it would break TypeScript code where users are already using variable names?
None of this pops up from the JS perspective. Theoretically using : or $ could both be valid compiler options.
Do you follow the JS Typed Comment standard? I was hoping it would be in JS24 alongside Pipes.
Both of those proposals are stage 1, and thus are likely years away from being in the language, if ever.
If you have a suggestion for a specific proposal, it might help to file an issue on that proposal's repo.
Thanks for explaining the TS / JS standard situation. Imagine a compiler option in Typescript to append all your core type info to the end of your variable names with $.
It's so simple it doesn't even need a standard if typed JS compilers added it as a completely optional compilation checkbox.
compilation output isn't type-checked, so what would be the benefit of having that information in the code? if there's a human benefit, wouldn't a comment have much more readability?
1 Like
Exactly its just immutable meta data. Like comments.
One benefit is then you can explore and introspect it in JS.
The big benefit is it might actually improve machine generated code readability.
x$i32 + y$f32
This is highly readable is it not? To see the nuance (in this case an error) in this calculation?
From one perspective, Typed Identifiers are "redundant" for writing. However redundancy can be helpful when reading (like from the middle of a program randomly).
If your a compiler or AI, the extra effort typing useful type text in a variable name isn't going to cause your hands carpal tunnel / strain.
You can’t introspect variable names in JS at runtime, though.
That makes it equivalent in impact to Typed Comments doesn't it?
I think of exposing Type at runtime in JS in terms of Objects and Keys and Object Literal notation where your program is literally a JSON document of all it's variables and functions.
The current proposal includes no runtime exposure of information.
Yes. Human Type Exposure and Runtime Type Exposure are different.
One key difference is Identifiers can be stored in JSON. Comments cannot.
The comment proposal is only in Stage 1 like you said.
"_" is a Identifier for if a object is Unused. There isn't a reason for "$" not being able to act as a Identifier for a Type. The entire point of a variable name is to describe a variable - types describe variables.
Edit: I am not proposing any new JS runtime type functionality. Just storing types in variable names with $... it doesn't hurt anything, like describing something in 2 words instead of 1.
Do you see what I mean now? Compared to comments, storing type information in Names is much better. Names are already Metatypes.
Is your main issue really that JavaScript would need a new identifier added or people would be upset? Even though its just metadata?
Does anyone else have ideas or objections or recommendations for how I could make this work?
Again, binding names aren’t information that can be used programmatically, and have no semantics now - which means they can’t ever suddenly have semantics. iow, names are not already metatypes and can’t become them.
It isn't adding semantics if it isn't used programmatically. Again, I am not saying variable names should suddenly be usable programmatically.
It's incredibly obvious that having a Type in a Name can be a good thing.
The semantics of putting $ in a variable name are completely optional and effect nothing.
If you still think I don't get it can you please give me an example of where your semantic problem would occur in real life?
Pretend tomorrow that Typescript adds support for this idea. Now, optionally, variable names can have their types compiled into them and JS TS code becomes readable in a new way.
In this scenario, who gets negatively effected? How is this hypothetical semantic social convention between TS and JS going to break anything?