On Tuesday, 14 June 2022 at 07:17:39 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 04:40:44 UTC, rikki cattermole wrote:
>> [...]
>
> how do I can explain this result in godbolt(using the -O paramater to ldc2):
>
> https://d.godbolt.org/z/hhT8MPesv
>
> if I understand the output correctly (and it's possible I don't), then it's telling me that there is no difference, in terms of the number of intructions needed, to allocate an int on the stack vs allocating it on the heap - no difference whatsoever. I don't get it.
>
> Is the outcome perculiar to just this simple example?

The compiler removed it, as you aren't using it,  naturally it looks the same.

Now tell the compiler not to be smart helping you,

https://d.godbolt.org/z/fY14oz86E

On 6/9/2022 12:20 AM, Paulo Pinto wrote:
> Swift, Ada, Modula-2, Modula-3, Rust, to pick only examples of languages that have an acknoledged identity as systems programming languages, had no issue considering calls into C and C++ unsafe.

There isn't a conversion problem when the language starts out as safe.

On Tuesday, 14 June 2022 at 07:34:29 UTC, Paulo Pinto wrote:
>
> The compiler removed it, as you aren't using it,  naturally it looks the same.
>
> Now tell the compiler not to be smart helping you,
>
> https://d.godbolt.org/z/fY14oz86E

I expect the compiler to be smart in helping me ;-)

In yet another example, the argument that 'less instructions are needed to allocate on the heap vs the stack', does not hold up to further scrutiny (at least in this optimised example).

https://d.godbolt.org/z/E85hWrocM

Presumably, the more complex the type of allocation be requested, the more difficult it is for the optimiser to optimise that request, and so you do in fact end up with more instructions for heap allocation. That is the only explanation I can come up with ;-)

But i leave further analysis to another thread ;-)

On Tuesday, 14 June 2022 at 00:16:37 UTC, Timon Gehr wrote:
> On 14.06.22 00:53, Walter Bright wrote:
>> On 6/9/2022 5:44 AM, John Colvin wrote:
>>> That is their fault
>> 
>> If the language encourages it, it's the language's fault.
>
> Exactly. You have literally been arguing in favor of the language doing this exact faulty thing _implicitly by default_. _That's_ what encouragement looks like.

I am normally on team “Walter’s been around the block a few times, he knows what’s up”, but this one just makes no sense at all.

I am working at what is presumably the largest employer of D programmers in the world, I was one of the very first using D there & I just can’t imagine us ever blaming you for encouraging us to blindly slap trusted on C bindings when the alternative was the compiler doing it implicitly!

On Tuesday, 14 June 2022 at 09:23:36 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 07:34:29 UTC, Paulo Pinto wrote:
>> [...]
>
> I expect the compiler to be smart in helping me ;-)
>
> In yet another example, the argument that 'less instructions are needed to allocate on the heap vs the stack', does not hold up to further scrutiny (at least in this optimised example).
>
> https://d.godbolt.org/z/E85hWrocM
>
> Presumably, the more complex the type of allocation be requested, the more difficult it is for the optimiser to optimise that request, and so you do in fact end up with more instructions for heap allocation. That is the only explanation I can come up with ;-)
>
> But i leave further analysis to another thread ;-)

Now you asked for too little help, with -O3 it is the same,

https://d.godbolt.org/z/M41EKvdT1

On 14/06/2022 9:23 PM, forkit wrote:
> In yet another example, the argument that 'less instructions are needed to allocate on the heap vs the stack', does not hold up to further scrutiny (at least in this optimised example).

It still holds up.

In both assembly no heap allocations took place. The compiler optimized it down to a register.

On 6/13/2022 6:32 PM, Adam D Ruppe wrote:
> On Monday, 13 June 2022 at 22:56:11 UTC, Walter Bright wrote:
>> The D compiler *does* keep track of this when it does attribute inference. Attribute inference is not currently done for regular functions because of the risk of mismatch between a function declaration and a function definition that may arise because of inference.
> 
> It'd cause a linker error though, right? This isn't really much different than any other mismatched header - and since we have dmd -H, it seems manageable.
> 
> I'll write a blog about this when I have time though. Been swamped with work lately but I do think there's some cases we have to be careful of but it should be doable.

Even with a linker error there'd be constant maintenance problem for the user.

On Tuesday, 14 June 2022 at 23:41:55 UTC, Walter Bright wrote:
> Even with a linker error there'd be constant maintenance problem for the user.

What maintenance problem?

When a library changes, it recompiles and generates its new interface file (if it even uses interface files; they're extremely rare in real world D code).

If the library hasn't changed, there's no need to update anything, inference or not.

This is near zero work.