Omar Kamel

Sure, but it's just one example of an interceptor-like pattern, since I don't think it matters _who_ does the actual invalidation

This is where static interfaces would be useful. Rust just... does this. ie: `() => T::fromJson(map)` Sadly, we're stuck doing `(T Function(Map) fromJson) => fromJson(map)`

Sounds like its just... static interfaces...? which would probably have to be virtually dispatched anyway, but for the sake of *much* improved DX and not needing to provide factories *when...

I actually don't agree with reusing .foo here, as I would personally take that to mean as `FunctionType.foo` which is not what you're looking for. I think it's important to...

I'm not really a fan of `.` Its kinda small and easily forgotten, whereas `_` to me reads "fill in" much like we use for "sign on the line" and......

we cant use the second option because that's a record. i don't see how `_` is overloaded. AFAIK its used as 1. "pattern match any" and later as 2. non-binding...

By that logic we can't use . either, since it would then have multiple different meanings. By using _() it does not overlap with _-as-wildcard nor _-as-nonbinding-variable because neither can...

Thats interesting, but wouldn't work, because we aren't checking constructors, (even though it looks like it) we're pattern matching. Therefore, .new() gives the wrong impression. I am of the opinion...

@lrhn I'd argue that "match anything" isnt to different to "match this". if we did: ```dart switch (thing as T) { T it => it // is T // vs...

> > `class _ {}` wont be possible once _ becomes non-binding as an identifier anyway (or... it should, else it would be inconsistant.) > > It's inconsistent. > Or...