Flow: Support `typeof x === "symbol"`

[mroch]

not sure what flow's support for Symbol in general is, but typeof x === "symbol" is not currently supported so we should fix that and whatever else is necessary for that to work properly.

[samwgoldman]

Support for well-known symbols would be really handy. For example, if we understood Symbol.iterator (and plugged that into dynamic object keys), it would be possible to define custom iterators for object types (Generators let us define iterables today, but in a more limited way.)

[indiescripter]

It would be a welcome improvement for Flow to properly support typeof x === "symbol" and related stuff for ES2015 symbols in general. TypeScript seems to be well-ahead in this regard.

[chyzwar]

I think there are two things,

One is proper support for the primitive data type of symbol.

  6: export type EventName = string | symbol;
                                      ^^^^^^ symbol. Could not resolve name

Second is support for common symbols:
@@iterator

[lll000111]

Open since 2015... come on guys, I can't check for "symbol"? Really??

In https://github.com/facebook/flow/issues/712#issuecomment-152624916 @mroch wrote

I fixed the exception in d45c099 and filed #1015 to make typeof x === "symbol" actually work.

Well... just typeof not causing an error would be a nice (and easy) start. This is independent of making symbols work, just checking if a variable is one is orthogonal to actually using them.

[bradennapier]

Any update here?

[devsnek]

so when will this actually happen?

[bradennapier]

:(

[kevinSuttle]

https://github.com/facebook/flow/blob/master/lib/core.js#L84 ?

[devsnek]

@kevinSuttle the Symbol primitive if supported, but specifically using typeof with "symbol" is not.

[lll000111]

Ping! 2015, and this is simple! For once, not just when saying so but when actually implementing it: All it takes is add "symbol" so that there is no complaint

Cannot compare the result of typeof to string literal symbol because it is not a valid
typeof return value.

No code checks needed, just stop that error. Actual full symbol support is of course a larger issues, but at least letting us CHECK without Flow complaining is as simple as it gets. I actually have such checks in a few places, such as values getting send over the network, to throw an error saying symbols are not supported, exactly in line with Flow, so why is Flow complaining??? I'm only doing its work here.

This is some really low-hanging fruit here.

[TrySound]

@lll000111 Is there a PR with this?

[lll000111]

@TrySound Ah, the guy who posts the most troll comments (not even close to the first time, here and now), welcome, I didn't actually miss you though. Do you feel you have to fill some comment quota but ran out of ideas long ago, so you just post whatever in so many threads, even if it has nothing to do with anything in the respective context?

By the way, you can now go ahead and copy your comment to thousands of other open and closed issues, you didn't tell everybody yet that in order to open or comment on an issue you have to always provide a PR. Because that's how it works, right?

I consider an issue open since 2015 for a very - very! - basic feature of the language that can be solved by someone who knows the OCaml code quickly reason enough. As I pointed out, this particular part is not even about full support for symbols.

Even more importantly. I guess you missed the fact that submitting a PR does not actually seem to help, Look at the list of open PRs. So what is your point? Oh of course, trolling, right.

[TrySound]

@lll000111 Ha-ha. I always felt that you are a big troll in this project. I never meant to troll, just trying to stay with my point of view.

I'm literally asking, did you see a PR which we could force? Because it will help.

Here's a PR which is imported to their internal repo. So it will be merged. And it's not the first time.
https://github.com/facebook/flow/pull/7271

If you want to continue crying about flow team unresponsiveness go to TS like people hyping these days.

[villesau]

Just a side note: Importing pull request does not mean that it will be merged. AFAIK FB has their internal review tools that they use instead of github. If importing means something, it can be interpreted in a way that they are _considering_ the proposed change. If you are more interested in that particular issue ( #7271 ), there is pretty interesting, even philosophical conversation about the topic: https://github.com/facebook/flow/issues/7128 If you think that my opinion is the correct one, you can show support by thumbing it up :)

If you are willing to contribute but don't now how to climb the OCaml mountain, this might help you forward: https://github.com/facebook/flow/issues/4181#issuecomment-447596374
They have some (pretty sparse though) documentation about flow internals in their wiki as well: https://github.com/facebook/flow/wiki/The-Flow-Codebase:-Introduction

[TrySound]

@villesau Well, yes. But at least being imported it will be considered.

[goodmind]

https://github.com/facebook/flow/pull/7405

[TrySound]

Merged. Will be in upcoming release.

[a7madgamal]

https://flow.org/en/docs/types/primitives/
I suppose someone needs to remove the mentioned ticket

[bugb]

agree with @a7madgamal, the doc seem has not been updated for a while!

[kevinbarabash]

I noticed that while:

function testSymbol(x: mixed) {
  if (typeof x === "symbol") { // ok
    (x: string); // error
  }
}

errors correctly, the following does not:

let x: mixed;
if (typeof x === "symbol") {
  (x: string);  // no error, should there be?
}

Is this difference in behavior intentional?