Ideal memory management in your dream PL.

Imagine you are designing a practical relatively low-level programming language to use instead of C++. What approach to memory management would you use?

In case someone asks, ``what is wrong with manly manual memory management in C++?'', I would briefly explain my disdain towards it. C++ strives to allow for efficient programs to be written, yet you have to jump through hoops and remember 30 different things if you want to avoid inefficiences C++ compilers inject into your application code. Where C would hit the spot with passing of pointers, C++ programmers need to know about RVO and const references and rvalues and perfect forwarding and noexcept declaration of copy constructors (why even have copy constructors anyway‽ how sane is having such thing‽) and reference collapsing rules. All just to prevent compiler from inserting procedures that needlessly copy your data multiple times here and there.

Instead of fixing a conceptually shitty design the committee adds 5 even more shitty things, each with its own semantics, each designed to work around one compiler/stdlib deficiency or another. Each has to be used manually.

So C++ programmers spend their brain cycles on recalling hundreds of shitty techniques while churning out code doing stuff which would be trivial for a saner language compiler to infer, instead of focusing on actual functionality.

Since it is lunch time where I work, I want to fantasize about a language/compiler which has most or all benefits of fast memory management (no GC), takes modern hardware into account, and doesn't fucking get in your way every time you pass a string to a function.

>>120
C's aliasing rules are a bit of a disaster, actually. Leaving aside the decisions to omit dynamic allocation and escape analysis from the language entirely (it's a systems language from the 1970s so these are somewhat excusable), aliasing is really the only thing left and they got it wrong.

Restricting aliasing by default makes programs much easier for both humans and compilers to reason about. There's always room for escape mechanisms like volatile for the few cases it's desirable to not constrain it.

>>121
Back when C was designed, there were no such words...
restrict is a very new keyword, compared to the overall age of C. They could not restrict pointer aliasing by default because then it would break 90% of existing C programs. Might as well call it C' then.

>>122
My point being that they should have had restrict semantics in the language by default from the very start. Contemporary languages (FORTRAN) already did this so K&R really had no excuse.

>>123
If you're talking about Fortran's array semantics, you simply don't understand the problem. The distinction between pointers and arrays is academic. They're the same thing under the hood. C was right to acknowledge this.

>>124

The distinction between pointers and arrays is academic

No, it most certainly is not. Array types and pointer types are distinct, even in C. Interchangeability of arrays and pointers in some contexts is a syntactic convenience, nothing more.

The problem with C is that a pointer can point to anything of compatible type, even if another pointer at the same sequence point already does, and it's impossible in general to tell if any two pointers to compatible types are pointing at the same thing at the same time. This confuses programmers and greatly constains the work optimizers can do.

>>125
You're starting to sound like a Rust advocate. Slow down before you hurt yourself. It's unsafe.

>>125

Interchangeability of arrays and pointers in some contexts is a syntactic convenience, nothing more.

If anything, arrays are a syntactic shorthand for pointer arithmetic. I can't think of any contexts where they're completely distinct.

The problem with arguing this kind of thing is C doesn't specify an IR. Under the hood the types are erased and arrays and pointers are indistinguishable. With an IR, there would be an ontological frame of reference to use to make your case. I'm not sure why you would bother arguing it, since you seem to be complaining that C doesn't make enough distinctions in the first place.

>>127

If anything, arrays are a syntactic shorthand for pointer arithmetic.

Actually it's the other way around. The standard is very careful to avoid providing any guarantees about what happens if pointer arithmetic is used to obtain an invalid array index.

I can't think of any contexts where they're completely distinct.

Definition, for one.

alias my anus

>>128

Actually it's the other way around. The standard is very careful to avoid providing any guarantees about what happens if pointer arithmetic is used to obtain an invalid array index.

Tomato, tomato. It's equally unconcerned with what happens if you use an invalid index.

Definition, for one.

That misses the point, you could achieve that with a simple transpiler. There is no ontological content. Can you think of another?

>>122

Might as well call it C' then.

Why an apostrophe?

>>130

Tomato, tomato. It's equally unconcerned with what happens if you use an invalid index.

If array semantics correctly show a an operation to be invalid where pointer semantics do not, the distinction is significant.

That misses the point, you could achieve that with a simple transpiler. There is no ontological content.

Please enlighten me as to the exact nature of this trivial transformation.

If array semantics correctly show a an operation to be invalid where pointer semantics do not, the distinction is significant.

I'm going to ignore this until you actually say something.

Please enlighten me as to the exact nature of this trivial transformation.

Useless, you're probably trying to enlist my help in building a strawman. If you want to argue the point, bring something that survives type erasure etc per the spec.

>>131
All the other punctuation marks are taken.

But why Sussman-san? Why me?

All the other ani are taken.

>>134
C.

>>136
Seedot?

C.
C.run
run.run

C💩