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
That example will crash because m has been orphaned from its Foo instance.
Strict this-checking aims to fix this issue.
this appears in the parameter list for functions and function types.
this types affect assignability of signatures:
typeEventA=(this: Element,x: string)=>void;typeEventB=(this: void,x: string)=>void;leta: EventA;letb: EventB;a=b;// Error: 'void' isn't enough for a method needing an 'Element' for 'this'.b=a;// Okay: No problem with getting *more* than you expect.
Assignability is still bivariant for a this parameter
In strict-this mode, the following's an error:
functionfoo(s: string){this.abc;// Error: 'this' is implicitly a 'void'.}
Arrow functions will always hold the value of this from their containing scope.
Free-standing functions implicitly get a void type for this.
Methods in classes implicitly have a this type of this.
Hopefully this is not very surprising.
This prevents incorrectly "ripping off the method" (this orphaning) from the first example.
Static methods have a this type of typeof Foo where Foo is the containing class.
Does this fix the bind function?
Almost!!
Why do we need a flag?
It breaks existing code for when your methods have no dependency on this.
Occurs several types in the compiler.
Problems sprout up between methods signatures and function type literals:
Joke of the day
Breaking Changes
"use strict" changes for modules (#3676)
emitNonStrictModules
."use strict"
for classes?Defaulting to built-in promises
async
/await
.async
code.Features (and potential breaking changes)
Specifying
this
types for functions (#6739)What does the "strict
this
" world look like?We will check
this
just as if it was an argument today.Consider
m
has been orphaned from itsFoo
instance.Strict
this
-checking aims to fix this issue.this
appears in the parameter list for functions and function types.this
types affect assignability of signatures:this
parameterIn strict-
this
mode, the following's an error:Arrow functions will always hold the value of
this
from their containing scope.Free-standing functions implicitly get a
void
type forthis
.Methods in classes implicitly have a
this
type ofthis
.this
orphaning) from the first example.Static methods have a
this
type oftypeof Foo
whereFoo
is the containing class.Does this fix the
bind
function?Why do we need a flag?
It breaks existing code for when your methods have no dependency on
this
.Occurs several types in the compiler.
Problems sprout up between methods signatures and function type literals:
Foo
methods implicitly get athis: this
type, whileBar
methods get athis: void
type!By default, without the strict-
this
flag, there will be no impliedthis
type.But we still want contextual typing to work correctly:
What about object literals?
If the object is contextually typed by
X
, methods will get thethis
type ofX
.An object literal with no contextual type just grabs the type of the object literal:
o
?Speaking of surfacing the representation of these types...
So are all these very big changes going to need these sorts of flags?
Do overload
this
parameters need to match?Unique types/tagged types/opaque types
People keep asking for this.
Ideas from last time:
The biggest question last time was what the behavior was for the type alias example (i.e.
Path
).We're thinking that
Path
will be printed asPath
.This approach, combined with intersections, allows you to "compose" on existing types.
You can write
Path & Lowercased
.Unique interfaces are useful for preventing people from forging nodes.
What about if a base is unique?
Does
unique
affect the static side?The text was updated successfully, but these errors were encountered: