A TypeScript boolean/undefined Flag variable kept fucking up
true == true didnt hold true

checked the "typeof" in console and it's GOODDAMN STRING.
What's the point of TypeScript's "type safety" if a Boolean variable is holding a String type for whatever reason. URGHH I HATE JAVASCRIPT.

oh and ofc "as Boolean" casting doesn't work I cannot check with == "true" coz according to TypeScipt, a Boolean variable cannot store String, OHHH IKKKRRRRR!?!?!?

I'll properly fix it later along with other possible instances of this family of errors
but the fact that it can happen is so annoying. A needless overhead.

Wtf.....?

Because you cannot have type safety. It is just an attempt at simulating type safety, but the language beneath it does not support it at all.

@ars1 yes but that's TypeScript's whole point
Im not expecting runtime checks coz ofc there can't be but I assumed TS would at least try to force-cast the primitive types where it can in the compiled JS and fail at runtime if it can't

The fact that I've to worry about this opens a whole can of worms coz now I can't trust "types"

Typescript isn't type safe. It has type suggestions.

> What's the point of TypeScript's "type safety" if a Boolean variable is holding a String type
> The fact that I've to worry about this opens a whole can of worms coz now can't trust "types"

The issue is you're lying to TS in the first place with type assertions (*not* casting) or any, and then expect it to magically solve it at runtime

@devRancid No no I did cast
Both "any"->"boolean" and then "any"->"string"->"boolean" when trying to fix it

If I were just throwing any and expecting magic, I wouldn't have ranted about it coz then it'd be on me

Ah wait @devRancid u right 💀
I looked it up n I was in the wrong

x AS y won't cast it'll just assert

Please provide an example, this is unusual.

@Ranchonyx this was the quickest recreation
also @devRancid acc to documentation "x AS y" is casting so idk anymore if I'm wrong or right -.-

@Ranchonyx copy pasting the code if it's too blurred to read:

function returningAny(): any {
return "true";
}

let booltest: boolean = false;
booltest = returningAny();

console.log(typeof booltest); //string

booltest = returningAny() as boolean;
console.log(typeof booltest); //string

console.log(booltest == true); //false
console.log(booltest == "true"); //says error but works, true

@azuredivay Well, that's expected behaviour.
Functions that are marked as returning 'any' can be assigned to basically every variable you declare.

TypeScript is only there for "compiler" errors / warnings, it doesn't transform your code to do runtime type checks.

It says error, but works because in JavaScript the comparison will return true.

And doing the "x as y" expression merely asserts. No real cast happening.

@Ranchonyx here it's just for demostration, IRL the external library is returning "any" so I can't change that but yea

I'll manually cast without the "as" which I def was relying too much on without knowing its limitations

I just assumed such a basic case would "obviously" be handled by TS compile-time but i assumed wrong

@azuredivay Oh, from an external library then. Big fucking oof.

Write a declaration merge to override the return type of it. Alternatively create a wrapper function for that flag.

Blame the 3rd party author for using any, that's a sin.

If you're writing javascript you prepare yourself for this kinda shit. I still write plain js. Being prepared, I never has such issues.

I can imagine that this took a while to figure out.

But the any type says a lot I guess.

Besides that it's fun, i don't see the point of typescript anyway

@retoor I legit thought TS enforces strictness at least for this level

My TS use is UI-only so such fuckups are tolerable to some extent
Knowing that ppl write entire backends in JS/TS makes me shiver ~_~

Id be anxious all day about every damn function/call

@azuredivay while i prefer python above JS, technically is python not much better I guess. Seeing the amount of mistakes a static compiler often shows of my work makes me really doubt the python i wrote before. Languages like python / js fail silently. The only thing to do is write a bunch of integration tests and fingers crossed.

I think most of us write the languages we like the most. Not because they're technically the best. Not that you as front end dev has a choice of language :P Back in dem days you could've used vbscript! And of course there is a python js library! Much upgrade :P

The term compilation is misleading, Typescript will check your type annotations and then remove them. The only Typescript feature that results in code generation is enums and it's the designers' self-proclaimed worst mistake. If you want something to happen at runtime, it has to be spelled out in Javascript.

By the way, Zod can do runtime checks and integrates nicely with Typescript.

Typescript doesn't do type checks for approximately the same reason that C doesn't type check pointer casts. Checking that a concrete value matches an arbitrary type is very expensive. It's also impossible in some cases, in C because there's no practical way for the program to determine whether a number is a valid file handle, and in Typescript because Typescript types are TC.

Isn't there an ESLint rule that flat out bans `as` casts? no-explicit-any catches the more heinous ones (as any as NonOverlappingType), but I frankly think that all legitimate `as` casts are exceptions that justify an allow directive and an explanation.

This is why TypeScript can never be great. The inclusion of the “any” type is required for JS compatibility, but completely renders the point of TS moot.

What a shame.

@AlgoRythm "unknown" instead of "any" solves that more or less

@devRancid tragically that was introduced in TS3, which is early, but not early enough to catch the cancer before it spreads. The any type having existed and still existing somewhat ruins the language :(

This thread is a great example of why.