Wishlist proposal, documenting fn arg as in or out or mod

[Cecil Ward]

On Wednesday, 21 June 2023 at 01:37:56 UTC, Cecil Ward wrote:
> On Tuesday, 20 June 2023 at 16:18:16 UTC, Dom DiSc wrote:
>> 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).
>
> We seem to have very different approaches. I like the fact that 
> const prevents me from modifying the argument inside the 
> function. I use that a lot. I never use ref apart from 
> by-ref-performance cases, although really the compiler should 
> deal with that and split the passing strategies according to 
> the size of the object in question.
>
> You’re wrong about the call site because I always then use 
> pointers and an & is visible at the call site. And there’s not 
> so much danger in a const pointer argument as there cannot be 
> any pointer modification although it can be stored externally 
> which is potentially bad.
>
> I’m not a C++ programmer and the first time I ever looked at it 
> I looked at &-ref and screamed, it’s like var parameters in 
> Pascal etc. C is just about all I known.
>
> So you can see I’m a dinosaur and am keeping it C-like by 
> default, unless I can see a good reason not to. Even though 
> there are so many things I am not too happy with in C now that 
> I’ve seen D and am starting to feel my way around it.

As you have all ready seen, I would like one small number of 
compiler internal behaviour changes regarding erroring things 
out, with no changes to existing programs, and one new keyword, 
which I now find we used to have anyway.

So not a huge thing to ask for. What do others think about my 
proposal. Only reply if you want what I want, don’t tell me ‘how 
it works’. :-) as I already get most of that.

>> Sorry, but if a function takes a "ref" that it never modifies, 
>> I would call this simply a bug.

I couldn’t disagree with you more, however…

>>It prevents you from calling
>> it with const or immutable arguments while this would be 
>> perfectly valid.

This is what has bitten me in the past, and that is indeed as you 
say ‘the bug’. I wish it could be fixed in the compiler, so you 
can pass immutable objects by ref to any functions that solemnly 
promise not to write back to them.

Thankyou for giving me further clue about why that evil might 
have been there.