Memory/Allocation attributes for variables

[sighoya]

On Thursday, 3 June 2021 at 17:26:03 UTC, Elmar wrote:
>
>```D
>@stack arr2 = dynamicArr.dup;   // create a copy on stack, the 
>stack is "scope"d
>```
>An easy but probably limited implementation would set 
>theAllocator before the initialization of such an attributed 
>value-type variable and resets theAllocator afterwards to the 
>allocator from before.


What if dup is creating things on the heap (I don't know by the 
way). You need to make the allocator dynamically scoped.

>
>```D
>@register: only stored in a register (with compile-time error if 
>not possible)
>```

Only if you have complete control over the backend.

Beside the combinatorial explosion in the required logic to check 
for, what happens if we copy/moving data between different memory 
annotated variables, e.g. nogc to gc, newcpp to gc.
Did we auto copy, cast or throw an error. If we do not throw an 
error, an annotation might not only restrict access but also 
change semantics by introducing new references.
So annotations become implied actions, that can be ok but is 
eventually hard to accept for the current uses of annotations.


>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 (even though C doesn't have it, C++ doesn't have it and 
>C# is no Systems Programming :-D ).

There is no such thing as memory transparency, strictly speaking, 
even if you want to allocate things on the stack, what is if your 
backend doesn't have a stack at all? Or we just rename the heap 
to stack?

In the end, we aren't that better what C or high level languages 
do, we have some heuristic though that our structures map better 
to the underlying hardware.

>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).


Well, I think having both is problematic/complex. But C has only 
one of those and C++ has both.
It's not quite correct what arrays belong, so that's a mistake.


>I think, any new language should remove the concept of pointers 
>entirely rather than introducing new pointers.

Why not removing the distinction between values and 
references/pointers at all? But I think it drifts to hard in a 
logically high level language and isn't the right way to go in a 
system level language although very interesting.

Annotations seam to be neat, but they parametrize your code:

```D
@allocator("X"), @lifetime("param1", "greather", "param2") void 
f(Type1 param1, Type2 param2)
```

becomes

```D
void f(Allocator X,Lifetime lifetime(param1), Lifetime 
lifetime(param2))(Type1 param1, Type2 param2) if 
currentAllocator=X && lifetime(param1)>=lifetime(param2) {...}
```

which literally turns every function allocating something into a 
template increasing "templatism" unless we get runtime generics 
as Swift.

To summarize, I find these improvements interesting, but
- doesn't feel system level
- at all possible in a 20 years old language?

Some Info: Rust distracts me in the point being a mix of high 
level with low level. They have values and references for their 
ownership/borrowing system but then also custom pointer types 
which doesn't interact well with the former.