Hi, I mean a specific valid runtime code should be able to run at compile
time. Nothing more. The following code is pretty much valid, but you can't
do it in compile time:
```cpp
alignas(alignof(T)) std::byte data[sizeof(T)];
new(&data) T();
std::launder(reinterpret_cast<T*>(&data))->~T();
```

Compilers can detect overflow, memory leak, etc and don't allow it in
compile time. I'd like to see a similar approach. Allow both placement new
and reinterpret_cast, if usage is valid. But that's too big of a ask I
think. So I thought something like std::typeless_memory or
std::typeless_storage could be something easier to implement and manage

On Sat, Nov 30, 2024 at 10:25 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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]> 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
>
> --
> 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
>