NagyDonat wrote: `<offtopic>` @steakhal > However, having nonloc::CompoundVals only make this worse.
Technically I didn't claim that they are better :sweat_smile:, and I can easily believe that they are indeed worse... > If I had to choose today, I'd only have LCVs for representing compount vals. I think non-lazy compound values are necessary from a theoretical POV to cover cases where we want to create a compound value directly (without "building it up" gradually in a state). For example, assume that we need to write an `EvalCall` for a function that construct a class object and returns it by value: this return value (which we want to bind into the `Environment`) is a compound value which cannot be expressed as a lazy compound value (because it is not the contents of a memory region that we model). (I admit that I don't know about a use case where we actually need an `EvalCall` like this.) > I'm pretty sure though that we could have nice APIs around it that would > bring consistency and no surprises. I agree and I hope that we can reach this eventually. `</offtopic>` https://github.com/llvm/llvm-project/pull/164600 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
