Hi Richard, responding here to a couple of points.
For bignums and for a type-descibing type 'type' there were proposals (including from me) to implement these as variable-sized types which have some restrictions, i.e. they cannot be stored in a struct/union. Most of the restrictions for these types would be the same as proposed for your sizeless types. Because all these types fall into the same overall class of types which do not have a size known at compile time, I would suggest to add this concept to the standard and then define your vector types as a subclass which may have additional restrictions (no sizeof) instead of adding a very specific concept which only works for your proposal. Best, Martin Am Donnerstag, den 18.10.2018, 13:47 +0100 schrieb Richard Sandiford: > Joseph Myers <jos...@codesourcery.com> writes: > > On Wed, 17 Oct 2018, Richard Sandiford wrote: > > > Yeah, can't deny that if you look at it as a general-purpose extension. > > > But that's not really what this is supposed to be. It's fairly special > > > purpose: there has to be some underlying variable-length/sizeless > > > built-in type that you want to provide via a library. > > > > > > What the extension allows is enough to support the intended use case, > > > and it does that with no enforced overhead. > > > > Part of my point is that there are various *other* possible cases of > > non-VLA-variable-size-type people have suggested in WG14 reflector > > discussions - so any set of concepts for such types ought to take into > > account more than just the SVE use case (even if other use cases need > > further concepts added on top of the ones needed for SVE). > > [Answered this in the other thread -- sorry, took me a while to go > through the full discussion.] > > > > > Surely, the processor knows the size when it computes using these > > > > types, so one could make it available using 'sizeof'. > > > > > > The argument's similar here: we don't really need sizeof to be available > > > for vector use because the library provides easy ways of getting > > > vector-length-based constants. Usually what you want to know is > > > "how many elements of type X are there?", with bytes just being one > > > of the available element sizes. > > > > But if having sizeof available makes for a more natural language feature > > (one where a few places referencing VLAs need to change to reference a > > more general class of variable-size types, and a few constraints on VLAs > > and variably modified types need to be relaxed to allow what you want with > > these types), that may be a case for doing so, even if sizeof won't > > generally be used. > > I agree that might be all that's needed in C. But since C++ doesn't > even have VLAs yet (and since something less ambituous than VLAs was > rejected) the situation is very different there. > > I think we'd need a compelling reason to make sizeof variable in C++. > The fact that it isn't going to be generally used for SVE anyway > would undercut that. > > > If the processor in fact knows the size, do you actually need to include > > it in the object to be able to provide it when sizeof is called? (With > > undefined behavior still present if passing the object from a thread with > > one value of sizeof for that type to a thread with a different value of > > sizeof for that type, of course - the rule on VLA type compatibility would > > still need to be extended to apply to sizes of these types, and those they > > contain, recursively.) > > No, if we go the undefined behaviour route, we wouldn't need to store it. > This was just to answer Martin's suggestion that we could make sizeof(x) > do the right thing for a sizeless object x by storing the size with x. > > Thanks, > Richard
