In addition Ada allows dynamically-sized arrays to be allocated on the stack and to be returned from a function. Efficient implement of the latter requires rather non-trivial support on the compiler side and C/C++/Rust have nothing like that. Yet in many cases it allows to eliminate new/delete and simplify code.

For example, just consider if C allowed to return a plain C string from a function without any heap allocation. Things like unsafe sprintf/strcopy would never happen then.

There a two stacks, the call stack, and a stack for returned values of dynamic size, not very complicated, is it?

Yes that is what I mean by allocation being handled by the compiler.

Although Ada still isn't fully memory safe. Read-before-write causes undefined behaviour, if I recall correctly.

Accesses - pointers - are automatically nulled when declared. So you won't silently screw up who-knows-what with an uninitialized access, though yeah, it's not perfectly safe.

You can also declare access types as "not null" in which case initialization is compulsory.

http://www.ada-auth.org/standards/12rm/html/RM-3-10.html#p13...

I didn't mean pointers/access-types, I meant ordinary integer-type locals.

You can put a pragma Warning_As_Error ("never assigned"); or the respective compiler switch on GNAT.

Other compilers have similar switch.

Heck even C and C++ have them, although few make use of them.

Also, I think Ada is fully memory-safe but for initialization. That is to say, the only way in which it's not memory-safe, is regarding uninitialized variables. (That's assuming of course that you don't disable checks.)

I'm not sure if it lets you shoot yourself in the foot regarding invalid type conversions, misuse of unions, that kind of thing.

Pragma Initialize_scalars for the win. But at runtime.

And if you can afford it, Codepeer (static analysis) finds most of the ones the compiler doesn't find. And then if you can live with the Spark subset, you get proof of initialization in 'bronze' mode :-).