On Sat, May 7, 2022 at 1:20 PM Jan Mercl <0xj...@gmail.com> wrote: > ^ Breaking the unsafe rules enables the code to behave non predictably. >
Sure, that's why I'm asking :) In the hope of either a) learning that it is, indeed, breaking the rules and thus should not be done, or b) learning that the rules are incomplete and eventually having them clarified. > AFAICT, interior pointers do and must keep the entire allocation block > alive, Is there any "official" documentation on the "must"? > but a sufficiently smart compiler is IMO free to ignore setting > of the 23 value - or allocating the actual storage for .Y in F(), > because no one can observe it - unless breaking the unsafe rules. > If internal pointers do, indeed, *must* keep the allocation alive, I can't see how this would be allowed. After all, the code is unambiguous about allocating a large object and returning a pointer into it - and if that pointer must keep the entire object alive, surely a compiler can't just decide to allocate a smaller one. FWIW it seems at least currently, gc is not doing doing it: https://godbolt.org/z/h74MchcT4 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEFcAWA8TN_UGv_dc8wbM%2BPZ1_ia0g18eGQ4hEju08vLg%40mail.gmail.com.
