Improve type inference of and / or

Description

When non-simple-boolean arguments are passed to the and and or macros, the type inferred is simply due to the inferred type of the nested if expansion. Instead we know that we could infer the last type in an and and the first type in an or (while properly handling clj-nil and perhaps also boolean).

Concretely:

can be inferred as type string and likewise

can be inferred as type number.

Environment

None

Activity

Show:
Mike Fikes
November 23, 2018, 4:44 AM

CLJS-2869-7.patch rebaselines

Mike Fikes
November 25, 2018, 10:08 AM

CLJS-2869-8.patch rebaselines

Mike Fikes
December 18, 2018, 2:18 AM

CLJS-2869-9.patch rebaselines

Mike Fikes
January 10, 2019, 12:55 AM

Note: If is applied then CLJS-2869-9.patch fails unit tests. (My guess is that this ticket's patch makes some assumption that, once is applied, is no longer valid---it is probably handling the clj-nil case explicitly in some way when it no longer needs to do so.)

Mike Fikes
May 12, 2019, 11:23 PM

We don't really need the complexity inherent in this, now that we have truths-induced inference, which covers a highly pragmatic case that this ticket was motivated by.

Declined

Assignee

Mike Fikes

Reporter

Mike Fikes

Labels

None

Approval

None

Patch

Code and Test

Priority

Major