[1ris]

Then i think i was wrong. For me this looks like it _added_ a whole lot of UB and made the rules of object provenance way more complex.

>The real problem is that C users have been lied to.

I think the real problem is that the committee is creating a language that the users neither need nor understand. The users want a language where pointers are, in fact, just address.

[Blaisorblade0]

Why don’t they just disable optimizations then? I think that’s because they also want performance, even when it requires pointers to not be just addresses.

And pointers weren’t addresses before either. My favorite example of “pointers aren’t addresses” is this kind of code:

int a[…]; int b[…]; /* … */ a[i] = 0; b[j] = 1; return a[i];

Ignoring this discussion for a moment, wouldn’t you expect `return a[i];` to optimize to `return 0;` here? After all, `a` and `b` are disjoint arrays! I’m sure many would be disappointed if the compiler did not do that optimization, right?

[1ris]

If i wanted the compiler to generate code for `return 0;` I'd write it that way. If i wanted to use c as my macro assembler i very much expect the compiler to _not_ make this transformation.

If I wanted language with clever optimisations I'd go for something way higher level like lisp, haskell. Most optimisations are often only useful to make sure you can program generically without a headache. Optimizing code generated by macros or monomorphisation/type specialisation/template instantiation/however you call it is really useful. Is it worth it otherwise? For me the difference between gcc -O1 and -O3 suggest this is not worth it in the domain where c is typically used.

[SAI_Peregrinus]

Optimizations don't really matter here. Optimization can't cause non-conforming code to be emitted (for a non-buggy compiler). A non-optimizing compiler could emit exactly the same code. If they don't, that's just inefficient code gen by the non-optimizing compiler.