> 20 февр. 2018 г., в 22:32, Mike Samuel <mikesamuel at gmail.com> написал(а):
> 
> 
> 
> On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <tj.crowder at farsightsoftware.com <mailto:tj.crowder at farsightsoftware.com>> wrote:
> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesamuel at gmail.com <mailto:mikesamuel at gmail.com>> 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 is:
> 
> @foo
> const x = initialValue
> f(x)
> 
> desugars to
> 
> const x = foo(undefined, initialValue)
> f(foo(x))
> 
> 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.
> 

I don’t understand how it will be comfortable to write decorators for checking arguments of every function with different set of arguments:

```
function a(b: PrimitiveNumber) {}

function a1({ x: PrimitiveBoolean, d: PrimitiveString }) {}

function a2(e: PrimitiveString, { f: PrimitiveNumber, g: PrimitiveString }, j: PrimitiveBoolean) {}
```

and etc. For every case I should to create separate decorator? It will also isn’t comfortable. And use decorators for locals for my goal me seems also more verbose and isn’t comfortable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180221/07da7874/attachment-0001.html>

> 20 февр. 2018 г., в 22:32, Mike Samuel <mikesamuel at gmail.com> написал(а):
> 
> 
> 
> On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <tj.crowder at farsightsoftware.com <mailto:tj.crowder at farsightsoftware.com>> wrote:
> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesamuel at gmail.com <mailto:mikesamuel at gmail.com>> 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 is:
> 
> @foo
> const x = initialValue
> f(x)
> 
> desugars to
> 
> const x = foo(undefined, initialValue)
> f(foo(x))
> 
> 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.
> 

I don’t understand how it will be comfortable to write decorators for checking arguments of every function with different set of arguments:

```
function a(b: PrimitiveNumber) {}

function a1({ x: PrimitiveBoolean, d: PrimitiveString }) {}

function a2(e: PrimitiveString, { f: PrimitiveNumber, g: PrimitiveString }, j: PrimitiveBoolean) {}
```

and etc. For every use case I should to create separate decorator? It will also isn’t comfortable. And use decorators for locals for my goal me seems also more verbose and isn’t comfortable.