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.

On 8/2/2024 1:34 AM, Timon Gehr wrote:
> 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_.

One reason for some of the builtin stuff is to not tempt people to write their own. Having standardized ways to do common tasks is a big win for making code understandable by others, which advantageous in a team environment.

For example, the `debug` conditionals came about from my discussions with a veteran Microsoft programming manager. He complained that every project invented their own scheme for doing debug conditionals, making it unnecessarily difficult to share code.

Unittests and Ddoc are other successful examples.

Lisp is a language that enables building one's one programming language on top of it. It more or less requires it.

The result is every Lisp user invents their own language, incompatible with any other Lisp user, and so successful Lisp programs don't survive their creators. It's why Lisp has never really caught on, much to the bafflement of Lisp advocates.

On 8/2/2024 2:29 AM, Dennis wrote:
> You would think it's safe to transform this:
> ```D
> printf("x = %s\n", x);
> printf("x = %s\n", x);
> ```
> 
> Into this:
> ```D
> const(char)* fmt = "x = %s\n";
> printf(fmt, x);
> printf(fmt, x);
> ```
> 
> But with magic printf format string rewrites, that transformation turns correct code into memory corrupting code when x is an int.

The transformation won't compile if the call is marked @safe, and won't compile with the various proposals to increase the default safety-ness.

It is in the same box as:

```
int[] array;
x = array[5];
```

and rewriting as:

```
int[] array;
x = *(array.ptr + 5);
```

On 8/3/24 18:54, Walter Bright wrote:
> On 8/2/2024 1:34 AM, Timon Gehr wrote:
>> 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_.
> 
> One reason for some of the builtin stuff is to not tempt people to write their own. Having standardized ways to do common tasks is a big win for making code understandable by others, which advantageous in a team environment.
> ...

Sure, I am in favor of built-in assert. This thread is however about magic.

> For example, the `debug` conditionals came about from my discussions with a veteran Microsoft programming manager. He complained that every project invented their own scheme for doing debug conditionals, making it unnecessarily difficult to share code.
> 
> Unittests and Ddoc are other successful examples.
> ...

Off-topic, but yes.

> Lisp is a language that enables building one's one programming language on top of it. It more or less requires it.
> 
> The result is every Lisp user invents their own language, incompatible with any other Lisp user, and so successful Lisp programs don't survive their creators. It's why Lisp has never really caught on, much to the bafflement of Lisp advocates.

Sure.

On 8/3/24 19:02, Walter Bright wrote:
> On 8/2/2024 2:29 AM, Dennis wrote:
>> You would think it's safe to transform this:
>> ```D
>> printf("x = %s\n", x);
>> printf("x = %s\n", x);
>> ```
>>
>> Into this:
>> ```D
>> const(char)* fmt = "x = %s\n";
>> printf(fmt, x);
>> printf(fmt, x);
>> ```
>>
>> But with magic printf format string rewrites, that transformation turns correct code into memory corrupting code when x is an int.
> 
> The transformation won't compile if the call is marked @safe, and won't compile with the various proposals to increase the default safety-ness.
> ...

The simple fact is that is that the magic treatment of the string-literal leads to some trouble. I.e., this is a good illustration about how magic instills fear.

> It is in the same box as:
> 
> ```
> int[] array;
> x = array[5];
> ```
> 
> and rewriting as:
> 
> ```
> int[] array;
> x = *(array.ptr + 5);
> ```

Not at all. You just orthogonally removed the range check. This is a completely unrelated case. Nothing surprising happens here.