Memory/Allocation attributes for variables

[Ola Fosheim Grostad]

On Tuesday, 1 June 2021 at 00:36:17 UTC, Elmar wrote:
> On Monday, 31 May 2021 at 18:56:44 UTC, Ola Fosheim Grøstad 
> wrote:
> I suppose you mean the "higher" level languages (because C is 
> by original definition also a high-level language).

Yes, I mean system level language vs proper high level languages 
that abstract away the hardware. "Low level" is not correct, but 
the usage of the term "system level" tend to lead to debates in 
these fora as there is a rift between low level and high level 
programmers...

> The thing I'd like to gain with those attributes is a 
> guarantee, that the referenced value wasn't allocated in a 
> certain address region/scope and lives in a lifetime-compatible 
> scope which can be detected by checking the pointer value 
> against an interval or a range of intervals. For example a 
> returned reference to an integer could have been created with 
> "malloc" or even a C++ allocator or interfacing functions could 
> annotate parameters with such attributes.

Well, I guess you are new, but Walter will refuse having many 
pointer types. Even the simple distinction between gc and raw 
pointers will be refused. The reason being that it would lead to 
a combinatorial explosion of function instances and prevent 
separate compilation.

So for D, this is not a probable solution.

That means you cannot do it through the regular type system, so 
that means you will have to do shape analysis of datastuctures.

I personally have in the past argued that it would be an 
interesting experiment to make all functions templates and 
template pointer parameter types.

That you can do with library pointer types, as a proof of 
concept, yourself. Then you will see what the effect is.

> lifetime region with equal lifetime. The comparison between 
> stack addresses assumes that an address deeper in the stack has 
> a higher or equal lifetime. The caller could also provide it's 
> stack frame bounds which allows to consider this interval as 
> one single lifetime.

How about coroutines? Now you have multiple stacks.

> I think, this is GC-related memory management, not type 
> checking. The memory attributes don't solve memory management 
> problems. The problem with reference counting usually is solved 
> by inserting weak pointers into cycles (which also solves the 
> apparent contradiction of a cycle of references). Weak 
> references are used by those objects which are deeper in the 
> graph of data links.

No, depth does not work, you could define an acyclic graph of 
owning pointers and then use weak pointers elsewhere. This 
restricts modelling and algorithms. So compiler verified 
restriction of non-weak references might be too restrictive?

So basically whenever changing a non-weak reference the compiler 
has to prove that the graph still is non-weak acyclic. Maybe 
possible, but does not sound trivial.

>  2. having static or dynamic (simple) value domain checks 
> (which checks whether a pointer value is in the allowed 
> interval(s) of the allocation address spaces belonging to the 
> attributes) which ensures that only allowed types of allocation 
> are used. These checks can be used to statically or dynamically 
> dispatch functions. Of course such a check could also be 
> performed manually but it's tedious and requires me to put all 
> different function bodies in one `static if else`.

Dynamic checks are unlikely to be accepted, I suggest you do this 
as a library.

> Where the feature shines most is function signatures because 
> they separate code and create intransparency which can be 
> countered by memory attributes for return type and argument 
> types.

Unfortunately, this is also why it will be rejected.

> Okay, I didn't define aliasing. With "aliasing" I mean that 
> "aliasing references" (or pointers) either point to the exact 
> same address or that the immediately pointed class/struct 
> (pointed to by the reference/pointer) does not overlap. I would 
> consider anything else more complicated than necessary.

Insufficient for D with library container types and library smart 
pointers.

> Do you think, it sounds like a nice idea to have a data 
> structure attribute `unique` next to `abstract` and `final` 
> which recursively guarantees that any reference or pointer is a 
> unique pointer?

Yes, some want isolated pointers, but you have to do all this 
stuff as library smart pointers in D.