On 12/23/20 12:48 PM, Eric Traut wrote:
 > David said:
 >> it's possible to trivially implement safe_cast()...
 >
 > Yes, but I'll point out that you would need to reverse the parameters
because the expression that is being narrowed (in your example, the
`value` parameter) must be the first param of the type guard function.

(The example of safe_cast() I provided doesn't actually use TypeGuard so
I'm assuming you meant cast(), whose definition is already fixed by the
existing API to have a typing form as the first parameter.)

Ah yes. It would be necessary to use explicit syntax in TypeGuard to
declare which (non-first) parameter was involved. Here's a corrected
definition of cast() that uses TypeGuard:

```
def cast(form: TypeForm[T], value: object) -> TypeGuard[value=T]:
     return value
```

On 12/23/20 4:48 PM, Sebastian Kreft wrote:
 >     I don't think that multiple arguments is the problem here. I've come
 >     across a couple of cases in real code where I wouldn't have been
 >     able to use the TypeGuard mechanism if it was limited to just one
 >     argument, so I'm reluctant to place that limitation on it.
 >
 > Note that it'd be just a deferral until we get more insights on how
 > typeguards are used in Python. Then we could extend TypeGuard to accept
 > an optional second argument specifying which argument is the one being
 > guarded, something like TypeGuard[T, 'second'].

I'll still advocate for a future syntax more like `TypeGuard[second=T]`
if the ability to explicitly label the applicable parameter appears
later. :)

To stress an earlier point, I do *not* think it's necessary to add that
kind of parameter-labeling syntax in the initial PEP, especially given
that for most uses of TypeGuard (ignoring combinations with TypeForm)
it's always the *first* parameter of the function that's being narrowed,
which doesn't require the labeling syntax. (If keyword arguments inside
[] were already available, I'd have a different opinion.)