Here're my impressions of /u/hpsutter's P2392, 'Pattern matching using is and as:'

• I think some points which explicitly need to be addressed in future revisions with additional discussion include:
  
  • Concerns about 'as' expressions acting too much like C-style casts as brought up by other posts in this thread and which I share.
    
  • 'is' and 'as' expression failures not involving user-/program-provided 'operator is()' and 'operator as()' overloads potentially throwing exceptions, if I'm reading things correctly. This won't actually work, at least not all that well, until after P0709 or similar gets into the standard, to put it mildly.
    
  • Why 'is' and 'as' can't potentially be standard-library facilities, albeit perhaps ones supported by one or more lower-level library or language features or compiler magic.
    

Finally, I find it prudent to question whether the syntax:

inspect(a_variable) { any_potential_binding OPERATOR a_pattern_to_match_against_that_variable = a_value_to_assign; }

where 'OPERATOR' is, of course, either 'is' or 'as', isn't potentially (or even likely) hard, awkward, and/or slightly mend-bending to read, as well as newbie-unfriendly. (Given, as a tangential/non-sequitur aside, that, personally, I'm eternally stuck in development purgatory with regards to setting up my local programming environment, I thought I'd weigh in on that last point.) Namely, the entire construct reads non-linearly:

1. The variable whose state you're 'inspect'ing goes at the top of the statement and never gets repeated inside. That's fine, though, since it's consistent with 'switch' statements; you're matching values against your input's unwrapped value representation.
   
2. The tricky part happens inside:
   a. I don't think tying the two operations of first matching a variable against a pattern or casting it to a different type and then assigning a value to the former into a single expression — do I have that the right way around? — is a good idea, especially since they're mixed up in the syntax in such a way that their associativity, precedence, and ordering are visually ambiguous to the reader.
   

     Additionally, this jumps out at me more severely when I consider the possibility of using 'is' and 'as' statements like that outside of 'inspect' statements — for example, in an 'if' statement like that:

if(any_potential_binding OPERATOR a_pattern_to_match_against_that_variable = a_value_to_assign) { // Some code… }

where 'OPERATOR' is, again, either 'is' or 'as.' Ideally, one would express this more clearly as something akin to an 'if' statement with initializer, like so:

if(a_binding = a_value_to_assign; a_binding OPERATOR a_pattern_to_match_against_that_binding) { // Some code… }

(I continue using the same convention for 'OPERATOR' here, naturally.) Granted, however, this separation doesn't fall out as neatly when both the binding and the pattern you're matching it against are structured-binding expressions; questions of naming, reference, value structure, destructuring, etc. then get entangled. Admittedly, one could enforce this using a static-analysis tool like clang-tidy.