You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Eventually the type system will be powerful enough to express the "signatures" of these functions, at which point their names will not need to be special-cased any more (since they can simply be declared to satisfy the necessary signatures).
In the short-term, we'll try to scope these names somewhat, so that they don't interfere with other things with the same names.
The proposal for refinement carrying boolean types in #34 isn't powerful enough, AFAICT, to express the type of invariant. Since TypeScript has already implemented that, it's probably a good time to start thinking about how we'd express something like invariant in the type language.
This uses the Ident "is" Type grammar proposed in #34. It uses @mroch's recent addition of boolean literals as Types. And it uses Flow's "this is an uncommon and undocumented" pattern of $Thing for communicating specific typing behavior.
I like this syntax and I think the syntax does communicate all the necessary information. I feel like the implementation might get tricky around the $Assert type, which should result in an abnormal event. I haven't looked into this enough yet to say whether it's realistic or not (maybe @avikchaudhuri can weigh in), but I'll give this some more thought.
3e35bd4 should get the rest of the static_upstream/core special cases out of the way, except for invariant. Renamed this task to preserve the discussion of predicate types.
No, %checks was built which is for predicate functions but not assertion functions. If this is a model the flow team is happy with then maybe something like this could be built such as %asserts?
Activity
avikchaudhuri commentedon Nov 24, 2014
Eventually the type system will be powerful enough to express the "signatures" of these functions, at which point their names will not need to be special-cased any more (since they can simply be declared to satisfy the necessary signatures).
In the short-term, we'll try to scope these names somewhat, so that they don't interfere with other things with the same names.
samwgoldman commentedon Aug 1, 2015
The proposal for refinement carrying boolean types in #34 isn't powerful enough, AFAICT, to express the type of
invariant. Since TypeScript has already implemented that, it's probably a good time to start thinking about how we'd express something likeinvariantin the type language.leebyron commentedon Aug 13, 2015
Here's a rough working but not long-term stable proposal:
This uses the
Ident "is" Typegrammar proposed in #34. It uses @mroch's recent addition of boolean literals as Types. And it uses Flow's "this is an uncommon and undocumented" pattern of $Thing for communicating specific typing behavior.samwgoldman commentedon Aug 13, 2015
I like this syntax and I think the syntax does communicate all the necessary information. I feel like the implementation might get tricky around the
$Asserttype, which should result in an abnormal event. I haven't looked into this enough yet to say whether it's realistic or not (maybe @avikchaudhuri can weigh in), but I'll give this some more thought.prevent facebookisms from stomping on innocent code
[-]Special cases for static_upstream/core[/-][+]Support predicate types[/+]mroch commentedon Jan 6, 2016
3e35bd4 should get the rest of the static_upstream/core special cases out of the way, except for
invariant. Renamed this task to preserve the discussion of predicate types.[-]Support predicate types[/-][+]Remove special case for `invariant`[/+]gajus commentedon May 22, 2018
Was this ever implemented?
leebyron commentedon May 23, 2018
No,
%checkswas built which is for predicate functions but not assertion functions. If this is a model the flow team is happy with then maybe something like this could be built such as%asserts?gajus commentedon May 23, 2018
For others reference, here is the documentation for
%checkshttps://flow.org/en/docs/types/functions/#toc-predicate-functions.gajus commentedon Jul 14, 2018
This issue is duplicate of #34.
mattconde commentedon May 27, 2019
So I think I've caught up on this issue, am I right to think I still can't flowtype my own "invariant" module correctly because of this?
goodmind commentedon Aug 4, 2019
TypeScript now has this microsoft/TypeScript#32695