Memory/Allocation attributes for variables

[Ola Fosheim Grøstad]

On Thursday, 3 June 2021 at 17:26:03 UTC, Elmar wrote:
> On Tuesday, 1 June 2021 at 06:12:05 UTC, Ola Fosheim Grostad 
> wrote:
> The separate compilation is a good point. Binary compatibility 
> is a common property considered for security safeguards. But at 
> least static checking with attributes would need no memory 
> addresses at all (also if the compiler can infer the attribute 
> for every value-typed variable automatically from where it is 
> defined).

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.

Nevertheless, it is being used as an argument for not making D a 
better language. So, that is what you are up against.

D isn't really "modern". It is very much in the C-mold, like C++. 
It has taken on too many of C++'s flaws. For instance it kept 
underperforming exceptions instead of making them fast.

> passes addresses obtained from variables. As a C programmer I'd 
> say that C's pointer concept was never needed as it stands, it 
> just was created to be an unsafe reference variable + a 
> reference + an iterator all-in-one-solution as the simplest 
> generic thing which beats it all (without knowing the use case 
> by looking at the pointer type).

C is mostly an abstraction over common machine language 
instructions. Making a non-optimizing C backend perform 
reasonably well for handcrafted C-code.

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

> Right, if nobody tried it so far I'd like myself. Then I can 
> firm my D experience with further practice. I'd compare the 
> nature of static and dynamic attribute checks to the nature of 
> C++ `static_cast` and `dynamic_cast` of class pointers. I was 
> thinking, such a user library could use `__traits` with 
> templated operator overloads.

Sounds like a fun project.

(D, as the languages stands, encourages the equivalent of 
reinterpret_cast, so there is that.)



> So, is that D's tenor that function signatures are thought to 
> create *in*transparency and should continue to do so? Does the 
> community think, allocation and memory transparency is a bad 
> thing or just not needed? IMO, allocation and memory 
> transparency is relevant to being a serious Systems programming 
> language

Let us not confuse community with creators. :). Also, let us not 
assume that there is a homogeneous community.

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.

> I probably should (try to) implement it myself as a proof of 
> concept.

The best option is to just introduce a custom pointer-library, 
like in C++, that tracks what you want it to track.

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?

Then you get a feeling for what it would be like.