Filip Sodić

To cover the use case from the issue's description (e.g., supporting both pages and routes for `to` fields in route declarations): ```css route OldLoginRoute { path: "/signup", to: LoginRoute }...

While researching, I stumbled upon the discovery that we are actually implementing union types (not sum types). The difference comes from something we've touched on several times in an unrelated...

Yes, it definitely makes sense for us. Haskell already has tagged unions, so they wouldn't be getting much out of adding untagged unions (i.e., tagged unions already cover most use...

We won't "penetrate" into type constructors (e.g., dictionaries, tuples). For example: ``` // this is inferred as [{ to: Route } | { to: Page }] [{ to: Route },...

We started writing tests and should continue from `inferExpr - Type checks a list of dictionaries that unify but have different types`. Summary: - We decided it was **OK for...

Today we implemented tests for `unifyTypes`.

- Finished the tests for `weaken`, haven't started editing `weaken` yet: c5bcea3d356eafdf5974ea11370cc8d722479df1 - Removed the function `unify` and changed a portion of `inferExprType` to prevent it from weakening list element...

We started working on a new branch (branched out from main): https://github.com/wasp-lang/wasp/tree/filip-martin-weaken. The main idea is to first simplify (or completely get rid of) `weaken` and its logic. That is...

> Thought: I believe doing manual optimistic updates, and doing manual cache invalidation, will turn out to be exactly the same thing, or at least very similarly thing. So it...

Hm, I'm guessing the arguments would represent a list of named imports with optional aliases? Sure, why not (although I think we already have a specific type that captures this...