New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support `typeof x === "symbol"` #1015

Open
mroch opened this Issue Oct 30, 2015 · 15 comments

Comments

Projects
None yet
@mroch
Copy link
Contributor

mroch commented Oct 30, 2015

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

This comment has been minimized.

Copy link
Member

samwgoldman commented Nov 6, 2015

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

This comment has been minimized.

Copy link

indiescripter commented Apr 28, 2017

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

This comment has been minimized.

Copy link

chyzwar commented Dec 3, 2017

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

This comment has been minimized.

Copy link
Contributor

lll000111 commented Apr 22, 2018

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

In #712 (comment) @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

This comment has been minimized.

Copy link

bradennapier commented May 30, 2018

Any update here?

@devsnek

This comment has been minimized.

Copy link

devsnek commented Aug 3, 2018

so when will this actually happen?

@bradennapier

This comment has been minimized.

Copy link

bradennapier commented Oct 11, 2018

:(

@kevinSuttle

This comment has been minimized.

@devsnek

This comment has been minimized.

Copy link

devsnek commented Oct 23, 2018

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

@lll000111

This comment has been minimized.

Copy link
Contributor

lll000111 commented Dec 27, 2018

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

This comment has been minimized.

Copy link

TrySound commented Dec 27, 2018

@lll000111 Is there a PR with this?

@lll000111

This comment has been minimized.

Copy link
Contributor

lll000111 commented Dec 27, 2018

@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

This comment has been minimized.

Copy link

TrySound commented Dec 27, 2018

@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.
#7271

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

@villesau

This comment has been minimized.

Copy link

villesau commented Dec 27, 2018

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: #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: #4181 (comment)
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

This comment has been minimized.

Copy link

TrySound commented Dec 27, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment