Make -preview=in means [ref] const scope and accept rvalues

[Geod24]

As explained in the changelog entry, this puts `in` more in line with its meaning:
that of an input parameter.
This change was prompted by the introduction of `-preview=in` to make `in` means
`const scope` (its original meaning). If we introduce a `preview` switch,
we might as well go all the way.

Needs test, I know, and won't pass the CI because druntime has scope const scope inheriting in.
But before I dig into making this work, I'd like to start the discussion on the concept itself.

The goal is to make in the "go to" type for input parameter. I had this in mind for a long time, and discussed it with @JinShil on some occasions.
Now that -preview=in has been merged ( #10769 ), I figured it would be the right time to introduce it, hoping to get his approved before the next release.

CC @atilaneves @WalterBright

[dlang-bot]

Thanks for your pull request, @Geod24!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#11000"

[kinke]

I think the optimal solution would be either const scope or const scope ref, depending on the type and target ABI, for the most efficient way to pass an input parameter. I.e., no ref (extra indirection) for class references and small PODs (incl. delegates and slices for most ABIs), but a ref for non-PODs and large PODs. To be coupled with -preview=rvaluerefparam as you've mentioned in the forum thread.

[Geod24]

@kinke : I agree. However, why limit it to in ? Could we make it an ABI thing that small types can be copied instead of passed by const ref when possible ?

[atilaneves]

I think this takes too much control away from the programmer. What if I don't want to pass by ref? Sure, I could declare const scope instead of in, but given that in D move semantics are achieved with pass-by-value, is ref something we want to encourage?

[kinke]

but given that in D move semantics are achieved with pass-by-value, is ref something we want to encourage?

(Optimized) DMD codegen: godbolt
LDC: godbolt
GDC: godbolt

And that's a trivial POD, no postblit/copy ctor and no move ctor either.

[kinke]

However, why limit it to in ? Could we make it an ABI thing that small types can be copied instead of passed by const ref when possible ?

You mean const ref T param could suddenly mean const T param for small PODs, and so &param yield something completely different? That won't work IMO.

Limited to in as a way to make this potential optimization transparent, and to give the user the possibility to check whether it's a ref or not via __traits(isRef) if need be.

Edit: The opposite direction, passing some suited by-value args by-ref under the hood, was discussed in lengthy https://forum.dlang.org/thread/oipegxuwqmrmmzefrqcx@forum.dlang.org, and later in a mailing list with Walter. That'd work with mutable params too, but it's not trivial.

[benjones]

Not sure if this is the best place to leave this, but Herb Sutter's preliminary proposal seems related. Basically, he says the programmer should specify intent (read only, output parameter, etc) and the compiler should choose whether things are passed by pointer or value and ensure legal usage: https://www.youtube.com/watch?v=qx22oxlQmKc&t=3454s

[Geod24]

@kinke : Good point, I didn't think about taking the address of it. And things like fiber context switch would make that visible to the user, even if scope is involved. So yes, having it selectively applied sounds better.

I think this takes too much control away from the programmer.

It doesn't take any control away. One is still free to apply the storage classes as one see fit. It doesn't restrict what can be done.

However, it makes it easy to do the right thing by default. You have an input parameter, you put in on it, and you're done. It's self-documenting and it doesn't make you think about the details of what's happening under the hood. It's all about making things easy in the common case.

Regarding move semantic, what @kinke said. The code generated by DMD is terrible, and uncontrollable (you can't prevent a struct being moved). Over the past two years, we've seen work in that direction:

• The accepted copy constructor DIP
• The accepted move constructor DIP
• Walter's pending DIP

The abstract of that last link directly mention copy elision as a goal for the DIP.

[Geod24]

Tests with my projects pass. Going to extend the usage of in and see if it holds, but this is definitely ready for review.

[UplinkCoder]

Wow this is a big one.

We should have left a Prefix character for mangle extensions ....

[Geod24]

Great, a Windows-only SEGV creeping in...

[kinke]

I told you so: #11000 (comment) due to

dmd/src/dmd/target.d

Lines 558 to 559 in de995df

	if (global.params.is64bit && global.params.isWindows)
	return null;

[Geod24]

Ah I missed that comment. So, any suggestion ?

[kinke]

IMO, just leave proper ABI handling to a follow-up.

[Geod24]

Works for me, reverted to the size check

[ibuclaw]

IMO, just leave proper ABI handling to a follow-up.

Right, the intent be fine though.

if (auto ts = p.type.isTypeStruct())
{
    if (ts.sym.numArgTypes())
         p.storageClass |= STC.ref_;
}
else if (auto tup = .toArgTypes(p.type))  // bypasses target.toArgTypes()
{
    if (tup.arguments)
         p.storageClass |= STC.ref_;
}

Just having a guess though.

[Geod24]

All green again.

[nordlow]

Wonderful!

[PetarKirov]

@Geod24 that's a great achievement, thanks for pushing it through! @kinke @ibuclaw and everyone else, thank you guys for the help as well!

[ibuclaw]