Supun Setunga

> replace TestFTTransfer and TestInterpreterFTTransfer with runtime tests that uses UseVM Removing this item, since the intention of the two tests `TestFTTransfer` and `TestInterpreterFTTransfer` (and their benchmark counterparts) was to...

Closing this as the underlying improvement is tracked via https://github.com/onflow/cadence/issues/2816

I have a different opinion :) Here LHS is a tuple destructure, and hence the context sort of knows the expected type/shape. Even now, it seems the compiler have correctly...

Now that we are done with major changes to the type-checker, and don't have any on-going work either, probably a good time to get started on this. I can have...

@onflow/cadence I guess this is no longer an issue for Cadence 1.0, given type requirements were removed?

The replacement for type-requirements is to use interface-type (or the concrete struct/resource type). Both of these are already supported in CCF. e.g: Intersection type with Interfaces: https://github.com/onflow/cadence/blob/08a4868d68d09bbbf61dd100ca37cb153838e60a/encoding/ccf/ccf_test.go#L7256-L7297

Like it was discussed in Discord (https://discord.com/channels/613813861610684416/1108479699732152503/1215366476882509876), interface/intersection types are not allowed to be used as event parameters, because the validation only occurs statically, and having an interface/intersection type allows...

> There are no nested type requirements in Cadence 1.0, no longer needed. To add more context: Alternative for type-requirements is to support interfaces in event-parameters, but that is going...

One more thing: `view` keyword is also not highlighted. Might be good to go through all new keywords and add any missing ones.

Yeah, can do. I'll have a look later today. In the meantime, were there any particular use-case(s) we wanted to enhance, or is this just a general improvement?