I would love to be able to document my arguments as in or out but also as read-write (like var in pascal, like fortran (?) and C++ D ref.

We already have "in". Good thing.

However it has got mixed up with const so that you can’t declare something as both. Is that right? I would like the compilers not to complain if something is declared as "in const" as there are two independent _intentions_ here, even though of course in implies const. Apart from that in is great. I use it everywhere. Small tweak.

Out is perfect as is.

However I hate using ref for input-output arguments as it isn’t visible at the call site and a ref could be just ref-for-implementation as in where you want to pass by reference to avoid copying a large object, but that has nothing to do with documenting the intention behind the in / out marking of the arg. Leave ref as it is for those who like it.

So I propose a new keyword either something like modified or mod or rw or input_output. Beauty contest, I don’t care what wins. (Shame inout is already taken.)

So my fn might look like

void myfn( in T1 InputArg, in const ref InputArray1, rw Modify, out result )

What do you think?

Then D would be as good as Ada in this respect, if I can remember from 40 years ago. ;-)

On Tuesday, 20 June 2023 at 15:01:17 UTC, Cecil Ward wrote:
> So I propose a new keyword either something like modified or mod or rw or input_output. Beauty contest, I don’t care what wins. (Shame inout is already taken.)

Fun fact: the reason `inout` is a keyword in D is that this is what it used to be.

Back on the old days, `inout` meant `ref`. But people kept asking so it got renamed to ref, and then inout was eventually reassigned to the const forwarding thing it is now (which was originally gonna be called `return` but never got implemented, and now `return` is used to indicate the lifetime of the parameter is the same as the return value, lolol)

Just to put it in clearer words:

On Tuesday, 20 June 2023 at 15:01:17 UTC, Cecil Ward wrote:
> I would love to be able to document my arguments as in or out but also as read-write

This is what "ref" is for.

> We already have "in". Good thing.
>
> However it has got mixed up with const so that you can’t declare something as both.

Hurray!
I'm so glad this is not allowed. "in" means const. There is no gain in "const const".

> However I hate using ref for input-output arguments as it isn’t visible at the call site

This is true for all annotations.

> and a ref could be just ref-for-implementation

Sorry, but if a function takes a "ref" that it never modifies, I would call this simply a bug. It prevents you from calling it with const or immutable arguments while this would be perfectly valid.
So "ref" is documenting that the function will modify this parameter. You can never expect anything else (or maybe curse the stupid developer that missed marking the parameter as const).

On 6/20/23 17:56, Dom DiSc wrote:
> 
> a "const ref" is of course read only, and a simple "ref" is expected to be modified by the function (else you would have made it const, wouldn't you?).

Absolutely not.

On 21/06/2023 3:01 AM, Cecil Ward wrote:
> I would love to be able to document my arguments

If you want a way to do it without compiler backed you can use UDA's:

```d
void main() {
    func(2);
}

enum MyThing;

void func(@MyThing int x) {
}
```

On Wednesday, 21 June 2023 at 00:55:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 21/06/2023 3:01 AM, Cecil Ward wrote:
>> I would love to be able to document my arguments
>
> If you want a way to do it without compiler backed you can use UDA's:
>
> ```d
> void main() {
>     func(2);
> }
>
> enum MyThing;
>
> void func(@MyThing int x) {
> }
> ```

Wow, I didn’t know that kind of tech was extensible like that. I really need the checking that the compiler does though, on in for example, making it const, and out presumably being either ref. (Or input-output passing of registers, seeing as having to have a pointer to a one machine word-sized value, say, that was in a register only one nanosec ago, is a bit mad. One hopes that the compilers might have a small size limit and switch to copy-by-ref only if args width exceeds that size.)

That could give me a way of starting full documentation earlier though.