Well, my use cases involve having a blob of memory store some types on
demand. One part is already mentioned via a paper linked in this
discussion: uninitialized memory at compile time for stuff like
inplace_vector. The other use case is polymorphism with making use of a
fixed amount of memory. Specifically I use it for an alternative
implementation of the std::function which is something else that cannot be
used at compile time.
The paper linked covers the first use case, but not the second one.
Note: I want flexibility of how you wanna guarantee memory used
appropriately, so I don't want the new standard type to have checks for
that. There is a lot of examples of "in compile time, compiler won't allow
UB, but in runtime you can do whatever you want"

On Sat, Nov 30, 2024 at 8:40 PM Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Sat, 30 Nov 2024 at 17:30, James via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Well, I can't say anything about being implementation defined or not.
>> What I can say is it's currently impossible, so for this to work either
>> standard needs to expand or make it implementation defined.
>> std::bit_cast creates copies which is not the same thing.
>> My main issue with the current state of the language is, you can do these
>> things at runtime.
>>
>
> What things? You haven't actually given an example of what you're doing at
> runtime and want to do at compile-time. Most type punning is not actually
> valid C++, although it depends exactly what you mean by type punning.
>
>
>
>> I have various constructs that make use of type punning, but I can't use
>> any of them at compile time. I need to have an alternative that solves the
>> same problem to be able to do it in compile time. Even then behaviour isn't
>> exactly the same.
>>
>> Regarding UB, compilers have all the information about literally anything
>> when it's executed at compile time. Compilers are smart, they can handle it.
>>
>> On Sat, Nov 30, 2024 at 1:45 PM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> The current typeless memory is either
>>>
>>> - std::byte, char, unsigned char
>>>
>>>
>>>
>>> As compile-time evaluation tries to avoid UB nearly completely and also
>>> tries to not use any implementation-defined features, there is less room
>>> for low-level inspection or modification.
>>>
>>>
>>>
>>> There is also constexpr std::bit_cast
>>>
>>>
>>>
>>> What usage examples do you have for the typeless_memory, which are not
>>> implementation-defined, allow the compiler to check and avoid UB (which
>>> e.g. entails an understanding of object lifetimes, types and memory
>>> locations) and which cannot be solved with the current tools in the
>>> standard library?
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* James via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Sa 30.11.2024 10:56
>>> *Betreff:* [std-proposals] std::typeless_memory (type punning)
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* James <james.business.84_at_[hidden]>;
>>> Currently you can do whatever you want at runtime when it comes to type
>>> punning. Sure, all of them might not be safe, but you have some ways to do
>>> it safely. However in compile time (as far as I know) there is no way to
>>> achieve type punning.
>>>
>>> So I'd like to see this type, in standard library
>>> https://godbolt.org/z/1dEjYW1hW
>>>
>>> It's only purpose is to allow treating some underlying memory as
>>> whatever type you want in compile time without using extra memory. It would
>>> also provide a shortcut for runtime usage
>>> Currently you can't achieve that due to placement new and
>>> reinterpret_cast not being usable in compile time context
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>