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.

[KtorZ]

@KristianBalaj but that's nasty IMO

That's one view point :)

@KristianBalaj One use case I have in mind is to filter inputs based on datum.

Now that's a use-case I can admittedly see as useful. So what you're asking here is basically some safe type-coercion. Which I think is reasonable. I wouldn't necessarily allow any expect matching to be turned into Option values because THAT would be nasty. If you want to assert the constructor of a particular data-type use when/is. However, being able to peak at an opaque data and assert for its type, that's useful.

Note that @MicroProofs is working on making Data available to pattern-matching which would allow doing exactly just that but would require you to have knowledge of the constructor index and shape of your type, which is kind of "advanced" and not the kind of experience we want to put to users generally speaking (but keep it as a possible low-level toolkit for the stdlib and whatnot).

So an option could be to introduce a new fn coerce(data: Data) -> Option<T> built-in function that would safely cast an opaque data into a known type T. This way, it's easy to use in combination with when/is or filtering functions and doesn't conflate with expect.

[rvcas]

This is along the lines of the typeof thing that Matt wanted

[KtorZ]

Kills two birds one stone. Perfect, I love killing birds.

[KristianBalaj]

The direction of this discussion sounds good to me 👌

[MicroProofs]

Coming up soon to be added

[colll78]

For anyone reading this before @MicroProofs adds some specific support for this.

You can currently check for the type of Data without expect by using the builtin functions which Aiken exposes.

https://aiken-lang.github.io/prelude/aiken/builtin.html

Ex start with choose_data:

choose_data(
  data: Data,
  when_constr: a,
  when_map: a,
  when_list: a,
  when_int: a,
  when_bytearray: a,
) -> a

[rvcas]

this is about to be released in #959