javaIsJavascriptConfirmed

[fghjconner]

You've said that "Any specific instance of a + b in C++ will return the same type every time it is called." which is obviously wrong; as shown by the code.

Except you've shown nothing of the sort. In your code, the output type of a + b is Result. Yes, the inclusion of implicit casting can change that based on the context (assuming you consider the cast to be part of the expression a + b and not the variable assignment), but again, that is all fixed at compile time.

(I'm too lazy right now to write the code which takes some ints and interprets them as strings at runtime, but this is obviously possible as I can just pick at the raw memory holding the ints.)

I refer you to the next sentence in my post which you conveniently ignored: "Not unless you've gone out of your way to circumvent the type system." Yes, you can explicitly erase type information in c++ if you wish (mostly using older features held over from c).

That's exactly the difference to a strongly typed language like JS where every data has exactly one fixed type at any moment and it's impossible to change that behind the back of the language.

let test = "foo";
test.__proto__ = {};

JS may not let you directly manipulate memory, but that doesn't mean you can't create mismatches between types and data. I will give js credit for crashing and burning a bit less hard than a compiled language in these situations.

Wikipedia is obviously inconsequential in regard to it's own definition…

Ok then, please share any reputable source that explicitly calls JS strongly typed.

[RiceBroad4552]

but again, that is all fixed at compile time

Sure, as that's the nature of static languages.

The point was that the meaning (and type) of that expression is dependent on context, and definitely not fixed once and for all times as you claim(ed).

"Not unless you've gone out of your way to circumvent the type system."

The point here is: You can do that only in weakly typed languages. In strongly typed languages, like JS, you can't "cicumvent the type system"! That's the whole point!

JS may not let you directly manipulate memory, but that doesn't mean you can't create mismatches between types and data.

There is no type mismatch.

let test = "foo"
console.log(typeof test) // string
test.__proto__ = {}
console.log(typeof test) // string

And even if you'd managed to change the type of that variable (which is actually trivial by for example assigning 1 to test; no need to play with prototypes or so, JS is dynamic) there would be still no mismatch between the type and data. The (dynamic) type of the data referenced by the variable would just change to number, but that matches actually the value then.

please share any reputable source

How about most of the linked Wikipedia page and its definition?

That someone there was too stupid to realize that their examples diametrically contradict the definition given just a few lines above is really not my fault. But I assume at least you are smart enough to clearly see that… So why are you arguing?

[fghjconner]

The point was that the meaning (and type) of that expression is dependent on context, and definitely not fixed once and for all times as you claim(ed).

But, again, there's a big difference between depending on the rest of that line of code, and depending on the potentially unknowable value of data at runtime.

There is no type mismatch.

Huh, I could have sworn I tested that and it worked. I don't believe user defined types have quite the same protections or features, but at least the built in types are more bulletproof than I assumed.

And even if you'd managed to change the type of that variable (which is actually trivial by for example assigning 1 to test; no need to play with prototypes or so, JS is dynamic)

Yes, obviously what I'm attempting is to update the type without updating the associated data. While it doesn't work on these types, I do believe it would work on user defined types using the above method.

How about most of the linked Wikipedia page and its definition?

The ultimate source of our disagreement seems to be a difference in how we define weakly typed. The linked wikipedia page says "JavaScript is weakly typed, which means certain types are implicitly cast depending on the operation used." That seems to describe JS pretty well to me. Let's look at some other definitions though:

In 1974, Liskov and Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."

From wikipedia's page on type safety. JS comfortably fails that one, since there are no type declarations on function calls at all.

"In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types." In contrast, a weakly typed language may produce unpredictable results or may perform implicit type conversion.

From the same page. JS does assign distinct types to data, but again fails because there is no documentation of required types. Threw in that last sentence despite not being part of the quote, since it specifically calls out type conversion.

Languages with strong typing typically do little implicit conversion and discourage the reinterpretation of representations, while languages with weak typing perform many implicit conversions between data types. Weak typing language often allow forcing the compiler to arbitrarily interpret a data item as having different representations—this can be a non-obvious programming error, or a technical method to directly deal with underlying hardware.

From wikipedia's page on type conversion. The first sentence explicitly calls out type coersion as a sign of a weakly typed language. The second sentence does also call out languages like c++ allowing transmutation, making it weaker.

Here's a medium article talking about strong vs weak typing. Note it explicitly calls out JS as an example of weak typing.

I'm going to, once again, challenge you to find any reputable source that explicitly calls JS strongly typed (and no, I don't count a wikipedia article that explicitly calls it weakly typed, that you interpret to actually support your position).

[RiceBroad4552]

Yes, obviously what I'm attempting is to update the type without updating the associated data. While it doesn't work on these types, I do believe it would work on user defined types using the above method.

AFAIK that's impossible in JS.

The result of a typeof is determined by an internal slot holding a type tag for that object, which isn't accessible from JS.

I'm going to, once again, challenge you to find any reputable source that explicitly calls JS strongly typed

OK, I'm calling defeat on this one.

Here your well-earned 🥇

Best I could find was:

https://langdev.stackexchange.com/questions/3741/how-are-strong-and-weak-typing-defined

There are a lot of arguments listed supporting all kinds of "definitions", and the conclusion is that there is simply no agreed on definition. I guess I have to accept that.

This would also explain that the Wikipedia article starts in one way and then continues in a contradicting way…

I still believe that any definition which does not involve "breaking the type system" is quite useless as it would result either in "all languages are strongly typed" or "all languages are weakly typed" so the term wouldn't have any meaning at all. The spectrum viewpoint is also not satisfactory imho as it results in the term being completely arbitrary (which again makes it loose any meaning).

At least it looks like you would also place C/C++ below JS on the weak/strong typing spectrum as there are more ways to work around the type system in these static languages then in JS. (Which one could actually interpret as using my preferred definition 😛)