[PATCH vkd3d 2/6] vkd3d-shader/hlsl: Move the common shape computation to expr_common_shape.
Giovanni Mascellani
gmascellani at codeweavers.com
Thu Oct 14 12:37:30 CDT 2021
Hi,
Il 14/10/21 18:09, Zebediah Figura ha scritto:
> Would it make more sense to instead pass the result of
> expr_common_base_type() to expr_common_shape()? I.e. something like
>
> struct hlsl_type *expr_common_shape(ctx, t1, t2,
> expr_common_base_type(t1, t2));
>
> or
>
> struct hlsl_type *expr_common_shape(ctx, t1, t2, HLSL_TYPE_BOOL);
>
> One of those things I think of when I see a function with a lot of
> output parameters :-)
I can do that, if you really want, but I like it less. First because
IMHO it uselessly subverts the dependencies between different pieces of
data: the process of computing the result type consists of two parts,
determining the base type and determining the shape. In principle they
are nicely independent (well, I think HLSL has some very awful corner
cases in which this does not happen, but for the moment we're pretending
only the nice part exists), while reading the code you're proposing I
would be led to think that determining the shape depends on which base
type you worked out. I find this confusing.
Also, this means that, for example in the case of the comparison
operations of patch 6/6, you have to call expr_common_shape twice, with
two different base types. Ok, not a big deal, but why make the code more
confusing for computing twice the same thing?
I don't like either passing three pointers to have three outputs from a
function, but that's what you get when your language doesn't have decent
support for anonymous product types (tuples). In Python the same thing
would have been very straightforward and idiomatic. And defining a
struct just to pass three values seems a bit excessive.
Does this make sense to you?
Thanks for the review, Giovanni.
More information about the wine-devel
mailing list