Do types need data location?

[gnidan]

@ekpyron thinks possibly yes, but my desire has been to separate types wholly from pointers, since semantically these might be viewed as purely separate concerns.

My original thinking might not be so sound, so I'm opening this issue to make sure this isn't forgotten.

[cameel]

I think we do need locations, but the way you built the pointer schema does satisfy this need. You can specify arbitrary locations for members of complex types. What you cannot do is restrict locations. I.e. you cannot have a struct with an array field that is guaranteed to be in storage. You can only say that it has to be an array and the pointer can place it where it wants.

I think this is fine because a debugger can expect the compiler to fill out the pointer correctly. Such restrictions are useful in the language to constrain the programmer, but are not necessary to drive the codegen.

[gnidan]

This does raise the question though, if those restrictions can be defined by a language, then maybe that forces us to treat the location as an essential part of the type? Like, maybe one could argue that, with only top-level restrictions on location, it's a separable concern. But I find it hard to argue against this inclusion when considering member-field location restrictions. If that's not part of the type representation, why are we okay with things like alignment/padding/etc. being part of the type representation?

And even if it's not relevant to codegen, it might be relevant to display concerns, when debuggers present the type? Programmers have to think about it when designing implementations... maybe I've changed my opinion since 2024 :)

(Obviously, it would have to be optional, since types can exist with unspecified location.)

[cameel]

If that's not part of the type representation, why are we okay with things like alignment/padding/etc. being part of the type representation?

It does not have to be a part of the type, but it has to be somewhere. Could just as well be a part of the pointer. Maybe that even would make more sense given that it's different in different locations. Is that actually how you wanted it to work? I assumed that the region does not have to match the size of the type exactly. And even when it does, you also have internal padding/alignment in some cases - I don't think collections have enough properties to fully describe what is currently possible with arrays of packed value types.

And even if it's not relevant to codegen, it might be relevant to display concerns, when debuggers present the type?

I think it's not. The string "abc" is still the same thing, no matter whether it's stored in storage using short representation or as a dynamic type in calldata tail or a string in memory or even a literal that does not have a physical location. The debugger may want to also display how that value is encoded and where but that's just the current internal representation, not an inherent property of the type.