You can't really check for the type of `Data` without `expect`

[KristianBalaj]

What is your idea? Provide a use case.

You can't really do the following:

type MyDatumA {...}
type MyDatumB {...}

let some_datum: Data = ...

when some_datum is {
   MyDatumA {..} -> ...
   MyDatumB {..} -> ...
   _ -> ...
}

You have to use expect and that will make the code fail, so you can't properly handle it if you want to.

Also the MyDatumA/B can have multiple constructors, so there needs to be some good approach for this.

Why is it a good idea?

It's a necessary feature in my opinion. You want to be able to pattern match the Data type without failing.

The problem is that constructors of different types can have the same index so the whole structure has to be compared and a compiler error needs to be raised in case of ambiguous pattern match (when 2 constructors can't be differentiated).

What is the current alternative and why is it not good enough?

You need to have MyDatumA and MyDatumB as constructors in the same type which makes it inconvenient.

[rvcas]

I'm not sure about this. I'd rather just allow Data to be pattern matched on directly. Not even sure this is possible actually.

[KristianBalaj]

In PlutusTx it's somehow possible.

This is the helper function I'm using in Plutus:

{-# INLINEABLE parseDatum #-}
parseDatum :: (PlutusTx.FromData a) => V2.Datum -> Maybe a
parseDatum da = PlutusTx.fromBuiltinData (Ledger.getDatum da)

In case the Datum (should work for Data overall) can't be represented as the a type, it returns Nothing.

EDIT: with such a function the above could be achieved.

[KtorZ]

I don't understand the point about multiple constructors? Perhaps that is something we need to explain better in the documentation but you do not have to settle on a particular constructor when turning some Data into a type T. You can simply:

expect my_concrete_type : T = data 

Where T can have multiple constructor. And here, there's little argument as to why you'd allow that to be manipulated as a first-class error if any. If an input isn't in the shape expected by your program, then there's no point continuing. If you need multiple shapes, then the best thing is to use a sum-type and have multiple cases.

[KristianBalaj]

@KtorZ Yeah you're right, the point regarding multiple constructors is irrelevant here. Since I want to match the type first, individual constructors of the matched type can be done afterwards with the language features that are available.

Yeah theoretically you could wrap all the constructors under a single type and then using the single type in all validators and pattern matching the right one, but that's nasty IMO.

One use case I have in mind is to filter inputs based on datum. I want to take only those datums that have datum of type T.
In such case the expect is useless since I don't want it to fail.