Hacker News Reader

Comment by dwheeler | Hacker News Reader

This is one advantage of Ada, where parameters are abstractly declared as "in" or "in out" or "out". The compiler can then decide how to best implement it for that specific size and architecture.

View on HN

> This is one advantage of Ada, where parameters are abstractly declared as "in" or "in out" or "out".

Also Fortran has "in", "inout" and "out".

Fortran also has «default» / no intent. This is somehow different from inout.

Also, MSVC has similar annotations for various static analyses: https://learn.microsoft.com/en-us/cpp/code-quality/understan...

And Swift also has "inout" parameters.

But not “out” params, sadly.

It can return multiple values, so this doesn’t matter much for value types, but it would be nice to be able to specify that a pointer arg is an out-param sometimes and enforce that it is not read from while handling allocation in the caller.

and GL/SL IIRC ...

So does Delphi / FreePascal

C++23 is not too late to the party https://en.cppreference.com/w/cpp/memory/out_ptr_t/out_ptr

So far as I can tell, it's not quite the same thing since these still have pointer semantics (and thus have to deal with aliasing etc). The in/out approach is more generic, since "in" can map to a pointer where it makes sense, and to a copy where it does not.

Better yet when you prohibit such arguments from aliasing (or at least make no-alias the default) - now the compiler can also implement "in out" by copying the value back and forth, if it's faster than indirection.

Ehh that's not quite what those are. The types being added for C++23 are designed for FFI.

Herb made a proposal for proper in/out parameters for C++ in 2020 https://youtu.be/6lurOCdaj0Y

How is that semantically different from Rust?

in - regular function arguments

inout - mut function arguments

out - function return

Is there any additional information that a compiler can infer from Ada’s parameter syntax?

The difference between passing by reference vs. by value is observable when comparing pointers to the original vs. to the argument. This difference may be unobservable in Ada though (not sure), so Ada would have more freedom choosing between the two.

A question to the Rust experts, would lifetime annotations 'a in Rust have similar benefit as "in" or "in out" or "out" in Ada and other languages? With the additional benefit in Rust where the compiler can deduce those automatically for most cases?

As a sibling comment points out, "in" is effectively equivalent to "&T", and "inout" is effectively equivalent to "&mut T". Rust is missing purely "out" parameters, but that isn't a very common case, and I'm not sure how much value there is in saying "this reference can't be read" since references are always guaranteed to be valid in Rust.

A Rust program can trivially return a tuple of values, so it doesn't need out params.

Out params are needed to ensure zero-copy in-place initialization of large objects, i.e. what C++ does with placement new. You can sort of fake it with MaybeUninit<> https://doc.rust-lang.org/std/mem/union.MaybeUninit.html but it's quite fiddly, requires unsafe code, and has undesirable effects on the layout of containing objects.

In–place initialization is nice to have, but not strictly required.

Dlang can also qualify parameters as in, out, and inout; although I don't know to what degree the compiler is able to use that for optimization purposes (it is used for safety checks IIRC)

Always curious how Ada solves ABI issue with such optimizations in place.

As long as the calling convention is deterministic from the declaration of the function it should be fine right?

If it's deterministic, the compiler cannot actually choose the best way to optimise it.

It just have to come up with the same best way each time?

At the minimum, the compiler can look at the size of the type to decide whether copying or indirection makes more sense. The size is stable for a given parameter signature and architecture, so the ABI is stable.

But also, the ABI only matters between two pieces that are separately compiled. A static binary optimized at link-time doesn't have to care.

Reply on news.ycombinator.com