Closed
Description
While updating the various .d.ts to have | null
and | undefined
, I came across some typings that use any
but don't allow null
or undefined
.
-
Object.defineProperty:
/** * Adds a property to an object, or modifies attributes of an existing property. * @param o Object on which to add or modify the property. This can be a native JavaScript * object (that is, a user-defined object or a built in object) or a DOM object. * @param p The property name. * @param attributes Descriptor for the property. It can be for a data property or an accessor * property. */ defineProperty(o: any, propertyKey: PropertyKey, attributes: PropertyDescriptor): any;
o
and the returned value cannot benull
orundefined
. -
Object.setPrototypeOf:
/** * Sets the prototype of a specified object o to object proto or null. Returns the object o. * @param o The object to change its prototype. * @param proto The value of the new prototype or null. */ setPrototypeOf(o: any, proto: any): any;
o
and the returned value cannot benull
orundefined
.proto
can benull
but notundefined
. -
etc.
I think there is value in being able to express both "This can be any type including null and undefined" and "This can be any type excluding null / undefined", but there is no way to express the latter.
Activity
yortus commentedon Mar 23, 2016
Seems conceptually similar to 'outersection' types, where you'd express it something like
any - null - undefined
, where you start with a type and 'subtract' other types from it.That issue is closed as too complex but there's a comment about it from a recent backlog slog that says: "Revisit in context of type operators"
Arnavion commentedon Mar 23, 2016
Yes, I remember, which is why I'm asking for a much easier form.
yortus commentedon Mar 23, 2016
This issue is probably going to come up more often when code starts using
--strictNullChecks
. In that mode types likestring
andnumber
will excludenull
andundefined
, but what aboutany
? Does that still includenull
andundefined
under strict null checks?In a way, it would seem consistent under
--strictNullChecks
thatany
excludesnull
andundefined
, and you would have to be explicit to include them, i.e.any | null | undefined
. OTOH that seems like a logical contradiction of the special semantics ofany
.Arnavion commentedon Mar 23, 2016
Yes,
--strictNullChecks
is the context of this issue, and yes since nullability is via union types,any
is allowed to benull
andundefined
. Hence this issue.yortus commentedon Mar 23, 2016
Maybe a new builtin type name like
some
orsomething
, wheresome | null | undefined ≡ any
jeffreymorlan commentedon Mar 23, 2016
This type already exists. It's
{}
yortus commentedon Mar 23, 2016
I don't think
{}
is the same thing at all. Using{}
as the return type in the OP's examples have a very different meaning thanany - null - undefined
or however it could be expressed.Arnavion commentedon Mar 23, 2016
Beat me to it :) For reference, see #5451 (comment)
Edit: Although atleast for the first case, a generic
T extends {}
with return typeT
should work?RyanCavanaugh commentedon Mar 23, 2016
{}
would be the equivalent type from the input side.On the output side, it would be
string | number | boolean | object
(note thatobject
is unimplemented, see #1809)Arnavion commentedon Mar 23, 2016
Thanks. It's a bit wordy, but I suppose the set of primitive types is well-known.
Is there any reason to use
{}
over that for the input side?RyanCavanaugh commentedon Mar 23, 2016
For callback parameter type annotations, one may be preferable over the other depending on the scenario.
yortus commentedon Mar 23, 2016
If function return types in
.d.ts
files are changed fromany
tostring | number | boolean | object
(for the purposes of excludingnull
orundefined
as in the OP's examples), wouldn't that break a lot of user code? Type assertions would have to be added where they were previously unnecessary onany
types. Not saying that's good or bad, just a big breaking change.RyanCavanaugh commentedon Mar 23, 2016
For return types, it's probably best to leave it as
any
. I'm not sure what use there is in saying "any but not null or undefined" since you're able to assign it to a non-null type anyway.Arnavion commentedon Mar 23, 2016
It would be self-documenting that it won't return a null. It may be useful for user functions as well that can return any object but never null, like a
parse(input, rule): output
function.jods4 commentedon Mar 27, 2016
This would be only for documentation purposes as TS allows dereferencing
any
or assigning to non-null variables.Ideas:
any | null
? This would be consistent with other types and OK for doc.!
going to fly for types as well? It could be useful with generics like:function nonNulls<T>(array: T[]): T![]
. If it does then maybe we should simply acceptany!
.35 remaining items
lemon-clown commentedon Aug 15, 2019
maybe you can try use

T extends null ? never : T
, as follows:nuts-n-bits commentedon Aug 24, 2019
Algebraic data type operators exist in TS.
Exclude<T>
,NonNullable<T>
seemed nice, until I tried them withany
, and they do work withany
.nuts-n-bits commentedon Aug 24, 2019
And by the way,
object | string | boolean | number
is bad form. Not to mention it'sobject | string | boolean | number | symbol | bigint
as of comment. Each time a new primitive is added you need to update it.cyberixae commentedon Oct 1, 2019
@mmkal Seems to be related to #13195
nuts-n-bits commentedon Oct 1, 2019
Try it out, it does not work. You'll find the appalling fact that
NotNil<any>
is now an alias ofnever
. This is because any extends anything.nuts-n-bits commentedon Oct 2, 2019
I appreciate that, however the title of this issue is explicitly non-nullable any.
michalburger1 commentedon Oct 14, 2019
any
doesn't mean that the value can be of any type. It means "please disable all type checking thanks". It doesn't make a whole lot of sense to "disable type checking except for null checks".To declare a variable that can be of any type you can use
unknown
. Sadly, you can't doNonNullable<unknown>
because it's not a union type, sostring | number | boolean | symbol | bigint | object
seems to be the only way to do this right now.cyberixae commentedon Oct 14, 2019
I'm ok with doing
string | number | boolean | ...
as a workaround but is there some way to display a custom alias likeDefined
orSome
in error messages instead of the full definition?I'm working with generated code which contains lots of statements about things that are defined and the error messagages are extremely hard to read because of such long definitions. See https://github.com/maasglobal/maas-schemas-ts/blob/master/src/core/booking.ts for example.
mykohsu commentedon Apr 6, 2023
With optional chaining, I think there is another use case?
Because an optional chained
any
is stillany
, a subsequent check on the assignednullable
parameter can make incorrect assumptions:Where as if there was a non-null
any
, comparing the optional chained result to null can be caught at compile time: