Windows experience is atrocious

[Steven Schveighoffer]

On 7/31/23 3:44 AM, Petar Kirov [ZombineDev] wrote:
> On Thursday, 27 July 2023 at 13:42:28 UTC, Steven Schveighoffer wrote:
>> `in ref` should just mean `in`.
> 
> I disagree. It should be `const scope ref` (i.e. arguments should always 
> be passed by reference). The use case for "always" ref is matching the 
> ABI of a third-party libraries or providing stable public ABI for the 
> current project itself. There's plenty of old code that used `in ref` to 
> mean `const [maybe scope(*)] ref`. Deprecating `in ref` caused a ton of 
> unnecessary churn and I don't think we gained anything in the end. 
> Allowing `in ref` is simpler (in terms of the effects it has on existing 
> code) and more effective (supporting a (perhaps niche) use-case, that 
> could otherwise be a blocker on the adoption of `-preview=in`).

`in` means `in ref` semantically (you assume it's passed by reference). 
So there's no benefit to specifying that physical pass-by-ref is required.

As for matching the ABI, I don't see this being a problem. You would 
have to be building a D project which relies on an old D binary without 
building the dependency with the same compiler switches.

And chances are *really* good that `in` means `ref` anyway. Cases where 
`in` might not use `ref` are something like `int`, or `byte`. Are there 
good use cases for accepting integers via const reference?

-Steve