Proposal to add symbol: "hasInstanceStrict"

Mike Samuel mikesamuel at
Tue Feb 20 18:32:01 UTC 2018

On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <
tj.crowder at> wrote:

> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesamuel at> wrote:
> >
> > I'm probably just going to echo themes that T.J. has dealt with better,
> but:
> Quite the opposite.
> And keying off Mike's excellent summary: I like the idea of providing a
> means of handling preconditions (and postconditions), of which runtime type
> checking is one example but only one. I'd just prefer to see it as a
> general mechanism than type-checking specifically.
> I suggest getting deep into the decorators stuff and helping push it
> forward, possibly into areas where it hasn't previously been headed (such
> as your `let x = sum(y, y)` where you want to have runtime type checking on
> what gets assigned to `x` -- as far as I know, that isn't even on their
> radar). Basically that's applying a precondition to the assignment to `x`
> (or a postcondition on the call to `sum`). Which could be interesting. You
> may or may not get agreement on pushing forward that far, but if you feel
> strongly about the functionality you're after, I see that as the direction
> to pursue. (Not that I'm in ANY way any kind of authority on moving things
> through the process here. Not remotely.)
> -- T.J. Crowder

One way that decorators (I keep saying annotations) for locals might work

const x = initialValue

desugars to

const x = foo(undefined, initialValue)

When the decorated local is used as a left-hand side, the use is wrapped in
a call to the decorator.
When the decorated local is used as a right-hand side, the value assigned
is the result of the decorator applied to the previous value and the
candidate value.

I think that would be enough to build guards upon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list