Fear of Compiler Magic

[Timon Gehr]

On 8/2/24 05:22, IchorDev wrote:
> I hear people complain about compiler magic a lot.

Probably this is partially inspired from here:
https://dconf.org/2018/talks/alexandrescu.html

> Yes, being able to do 
> everything in-language is nice, but compiler magic is inevitable and 
> also can be very useful. `assert` is my favourite example.

int foo(){ enforce(0); } // error
int foo(){ assert(0); } // ok

"No compiler magic" would e.g. mean: `enforce` can similarly influence 
definite return analysis. It's not inevitable that this is impossible.

> Things like 
> Python’s `print` are more dubious. You can always make a better print 
> function on your own, right? Whereas one assert is never going to 
> transcend another assert, even if the way it prints its assertion 
> failure is slow, who cares? The program is already functionally dead 
> anyway. Do we really want C’s ‘everyone assert for themself’ problem?

Well, this is what assert does. The question is how it achieves it, and 
whether the same tools are accessible to user code that perhaps does 
_something different than assert_.

> And besides that, isn’t ‘compiler magic’ at its logical conclusion 
> generally applicable to *any* task performed by the compiler?

Not if the tasks are properly decomposed into orthogonal components that 
are also available to the user. Anyway, there is quite a bit of existing 
magic, and it does cause some issues.