Partial Record Field Access

[ken-underscore]

type MyDatum {
  Datum1 {
    prop_a: ByteArray,
    prob_b: Int
  }
  Datum2 {
    prop_a: ByteArray,
    prop_c: ByteArray
  }
}

I have a scenario where I am spending 2 outputs from a script, one output will have Datum1 and one will have Datum2, but in this scenario the only thing I care about is prop_a from each. It would be convenient if I didn't have to determine the type of the datum and cast the Data object to the correct type but could instead just access prop_a which I know will be there either way. I'm not sure if this would provide a performance benefit (possible to avoid type casting the whole object?) or just give a more concise way to access the desired property in this scenario.

[rvcas]

At the moment, you may know it's there but the type system does not. It only ever sees that it has some Var of type MyDatum. What you suggest would require some extra type system work and that's not unreasonable. We would also maybe want some new syntax to turn on this kind of thing during field access so that we can generate the machinery to make sure it's safe under the hood by returning errors. So at runtime it would likely still cost as much as using a when pattern match. This isn't a situation where casting applies or helps. You don't cast to Constructors (type members), those are just values. When casting you would specify MyDatum to convert from Data. Even in a pattern match atm you can't field access on something with many constructors. I do really think we'll ever do something like this.

[rvcas]

Oh I answered a different question. You are asking to not have to cast from Data to MyDatum and still do field access. That's never going to happen at all. Datum is user provided and SHOULD be checked by casting with expect, we cannot guarantee the soundness of your contract if we were to enable this, it's not a good idea. This is the kind of situation where you shouldn't let a desire for convenience push you into the direction of writing contracts with vulnerabilities. Datum and Redeemer are user input and therefore can contain potentially malicious payloads that cause "undefined behavior".

[ken-underscore]

Thanks I appreciate the extra context. I think my misunderstanding of some things made my comment less clear, the situation I am thinking about is when we know the Data is of type MyDatum already and I'd like to access prop_a. So in this case I was wondering if it was possible to skip the pattern match, the thought came from seeing a similar situation in plutus tx code where an accessor function is called on the MyDatum type for a property that was present on all versions of MyDatum, but I wouldn't be surprised if as you say you're not actually saving yourself anything here in terms of performance. Ktorz mentioned this could potentially be a kind of syntactic sugar to avoid doing a "let when is" to get the property, which I think would also be beneficial but probably not high priority

[rvcas]

yea that makes way more sense to me, something like that is reasonable.