Memory/Allocation attributes for variables

[Elmar]

On Friday, 4 June 2021 at 08:29:47 UTC, Ola Fosheim Grøstad wrote:
> I don't think separate compilation is a good point. I think a 
> modern language should mix object-file and IR-file linking with 
> caching for speed improvements.

I know what you mean. Avoiding separate compilation where 
possible allows for more optimization potential but in general 
you can't avoid it, particularly when source code is not 
available. D tries to be linkable with C and C++ which don't know 
D. That's why working with separate binaries needs to be 
considered (and compatibility with C/C++ really is important 
because both languages have large code bases). So with "good 
point" I meant "an important aspect" in research, not that it's 
nice to need it :-) .

> C pointers do have a counterpart in C++ STL iterators though. 
> So, one could argue that C-pointers are memory-iterators.

Exactly.

> So, you have the scripty-camp who are not bothered by the 
> current GC and don't really deal with memory allocations much. 
> Then there is the other camp.
>
> As one of those in the other camp, I think that the compiler 
> should do the memory management and be free to optimize. So I 
> am not fond of things like "scope". I think they are crutches. 
> I think the language is becoming arcane by patching it up here 
> and there instead of providing a generic solution.

`scope` exists for a good reason because guaranteeing compiler 
optimization is very hard (apparently). The `scope` attribute has 
two benefits: 1st it makes RAII explicit (which helps to prevent 
bugs by falsely using it), 2nd it makes the compiler faster and 
easier because it doesn't need to understand the code in order to 
search for optimization places.

Performing optimization is easier than finding the places that 
can be optimized and then assuring the correctness of 
optimization. Finding all optimizations automatically (the ideal 
case) probably would explode compile-time so therefore attributes 
are given to programmers for hinting them, it solves the 
compile-time issue and reduces compiler complexity a lot.

The problem with genericity is, it's always a tradeoff with 
efficiency. It makes coding more complicated and the solution 
more heavy (because it takes care about more cases), at some 
point too complicated to be practical.

There are cases were the compiler cannot know in any way the 
correctness of an optimization because it depends on the 
programmer's intend (or would change behaviour). Then, explicit 
optimization hints are required.

> Don't bother with separate compilation issues. Just template 
> all functions. I think LDC will remove duplicates if the bodies 
> of two functions turn into the same machine code?

I'm almost certain that duplicate functions will not be removed 
in all cases, because that's a very difficult problem to solve. 
It just reminds me of the undecidability of the Liskov 
Substitution principle according to Wikipedia. This principle 
requires that contracts/halting still hold with subtype arguments 
passed to a function.

Have a nice day.