On Tuesday, 20 June 2023 at 22:17:13 UTC, ryuukk_ wrote:
> On Tuesday, 20 June 2023 at 16:12:35 UTC, Adam D Ruppe wrote:
>> On Tuesday, 20 June 2023 at 15:01:17 UTC, Cecil Ward wrote:
>>> [...]
>>
>> 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)
>
> ``return`` thing is the most stupid thing ever, whoever approved this needs to stop

The Horror!

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.

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.

On 6/21/23 4:51 AM, Dom DiSc wrote:
> On Tuesday, 20 June 2023 at 20:44:42 UTC, GrimMaple wrote:
> 
>> `const ref Type` makes 0 sense, because all references are `const` already (you can't change the _reference_, you can change the _referenced object_). What you probably want to mean is `ref const(Type)` instead, making it a const reference to a const `Type`.
> 
> Oops. This is really stupid. Then you are right, it should always be "ref const(T)".

`const` is both a type modifier, and a storage class. When used as a storage class, it means the type specified is attributed with the `const` type modifier. In certain contexts, it also can indicate that the variable should be stored in ROM.

So `const ref Type` makes sense, the `const` means "apply the `const` type modifier to the stored type".

So `const ref Type` is the same as `ref const Type` or `ref const(Type)`, the canonical form.

> So the nicer syntax is simply useless and confusing?
> If anything, I would propose to change that:
> "const ref T" should be identical to "ref const(T)"

It does mean this.

-Steve

On Friday, 23 June 2023 at 02:24:07 UTC, Steven Schveighoffer wrote:
>
> `const` is both a type modifier, and a storage class. When used as a storage class, it means the type specified is attributed with the `const` type modifier. In certain contexts, it also can indicate that the variable should be stored in ROM.
>
> So `const ref Type` makes sense, the `const` means "apply the `const` type modifier to the stored type".
>
> So `const ref Type` is the same as `ref const Type` or `ref const(Type)`, the canonical form.

Pew, ok. I was just about to change a LOT of my code...
Glad I'm not as stupid as I thought.