On Fri, Oct 10, 2025 at 12:08 PM Jesung Yang <[email protected]> wrote: > > That said, it becomes a bit trickier when dealing with conversions > between signed and unsigned types, particularly when `u128` and `i128` > are involved. For example:
Yeah, it is why I said it was a dummy unsigned case -- I didn't mean that single comparison would work for all cases. But what case do you think we cannot assert? We can always take the discriminant and reject whatever inputs (e.g. ranges) we decide, no? And we know what type we are going into, so we can always decide what the values to check will be, i.e. we could in principle even support infallible conversions of the discriminant to other types like, say, the bounded integers or powers of two. Maybe the issue is in what you say at "the discriminant value interpreted as the target type" -- I am not sure what you mean by "interpreted", i.e. I would think of this as accepting only some bit patterns, i.e. working with in the discriminant space, not the target type one. I may be missing something, but in any case, at the end of the day, within a proc macro "everything" should be possible one way or another -- even if we had to inspect manually the literals :) And it seems worth to remove the pitfall. If really needed, we can always drop support for certain combinations. We already do, in the sense that we don't cover every single other type out there, like the ones I mention above, e.g. `Alignment`. But, just in case, I assume with that approach you mean skipping some combinations early (the ones that cannot be checked) and then still asserting the discriminants, right? Otherwise the caveat is still there. Thanks! Cheers, Miguel
