But it's not. And there is no reason why getting the size out of a fat pointer at runtime would need to be done by the same syntactic construct that otherwise does static calculations.
Duh, C also doesn't have fat pointers. And C doesn't have a runtime_sizeof keyword. How do you get from this to "The existing sizeof should be re-purposed to be evaluated at runtime"?
It is a tool I use all the time. I am not concerned about keeping an unaltered timeless gem (which it isn't), but rather things like clarity, orthogonality, simplicity, minimality of concepts etc.
Honestly I am not even sure I am missing fat pointers, other than getting some better diagnostics in pretty rare cases of out-of-bounds access. For coding, I much prefer separate, explicit length fields. I can have as many of them as I need and mutate them as I need. Much more flexible.
The hidden size field of a fat pointer would be more appropriate for a "capacity" field (think std::vector capacity() vs size()) since that is indeed -- more or less, usually -- immutable after allocation of the buffer.
However that is not the "size" field that most would be interested in, not the size field that defines that range of valid data. So again, would be mostly useful for diagnostics, and only if there is a well defined allocation size.
There are some other concerns I have with fat pointers. Let's consider two fat pointers with the same address but different length, how should they compare, p1 == p2 or p1 != p2? Neither p1 < p2 nor p1 > p2 would be a good choice, they would both probably break a lot of code. There is probably quite a lot of code that deducts p1==p2, however substituting p2 for p1 could lead to breakage due to different lengths.
This seems to me like a strong argument against fat pointers, seeing that problems arise from too much magic. While it could be made to work with the standard (since I guess doing any comparison between p1 and p2 could be UB considering p1 and p2 as pointing to different "objects" / one of them invalid), it's probably a path I would not want to go down.
Another, less theoretic and much more practical concern is this: How do you plan to make fat pointers compatible with existing software? If the normal pointer syntax is taken as-is and repurposed to represent fat pointers, those fat pointers will now be bigger than before. I suppose that a good chunk of existing projects would break, and would require significant porting work.
It is ratholes like this that WG14 seems to have mostly avoided rather successfully, and I value that. If you want more features, there is a different language with another philosophy, so no reason for posting negative sentiments (including subtle aggression like "hit by a bus" etc).
