Hi James, do you want to achieve something in compile-time, which is currently not possible in compile-time, and should be. Or do you want to achieve it in the same way, as is currently done or possible in runtime? To have identical code?   The question of UB is a central one: If it can be legally used in runtime, it is no UB (by definition). You brought up adding two signed integers. Signed Overflow is UB, but signed addition itself (without overflow) is okay.   If it just works with current compilers, but is illegal, it is UB.   However, there are legal cases for reinterpret_cast for runtime code, but it is forbidden in compile-time code. So you may have a point or use case, which should be made possible in compile-time code.   There are also illegal cases of reinterpret_cast & Co., which are often used and sometimes work in runtime code by pure luck.   However, the optimizers get better and better [and we will have LLM AIs in the future in the IDE and in the Optimizier, which suggest many correct and not-correct code rewrites/optimizations and a proof engine will proof whether, the rewritten code is correct, as long as no UB happens; the fastest will actually be compiled or the nicest looking will be kept in the IDE] and UB code will have less and less luck.   "Compilers are smart, they can handle it." Just be careful that they do not outsmart you as programmer. The most difficult problem for programming is to exactly state, what you mean. UB is not even a valid sentence (program) at all.   Also C++ as a whole goes more and more in the direction of safety and safety profiles. Anything relying on current runtime hacks could also be difficult to compile with activated safety profile in the future.   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:James via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 30.11.2024 18:57 Betreff:Re: [std-proposals] std::typeless_memory (type punning) An:Jonathan Wakely <cxx_at_[hidden]>; CC:James <james.business.84_at_[hidden]>; std-proposals_at_[hidden]; 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 Sesomething 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] <mailto:cxx_at_[hidden]> > wrote:   On Sat, 30 Nov 2024 at 17:30, James via Std-Proposals <std-proposals_at_[hidden] <mailto: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] <mailto: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] <mailto:std-proposals_at_[hidden]> > Gesendet:Sa 30.11.2024 10:56 Betreff:[std-proposals] std::typeless_memory (type punning) An:std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> ; CC:James <james.business.84_at_[hidden] <mailto: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] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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