-preview=in might break code

[Ola Fosheim Grøstad]

On Saturday, 3 October 2020 at 15:58:53 UTC, Steven Schveighoffer 
wrote:
> Given that it's a parameter, and the parameter is const, it can 
> only change through another reference. And this means, the 
> function has to deal with the possibility that it can change, 
> but ALSO cannot depend on or enforce being able to change it on 
> purpose. On that, I think I agree with the concept of being 
> able to switch to a value.

But you can expect it to not change in parallell as it is not 
shared!? It can change if you call another function or in the 
context of a coroutine (assuming that coroutines cannot move to 
other threads).

My key point was this, I've never seen "ref" mean anything else 
than a live view of an object. If D is going to be an easy to 
learn language anything named "ref" has to retain that 
expectation.

In the context of parallell programming I believe that Chapel has 
various parameter transfer types that might be worth looking at 
(I don't remember the details).

> What I don't agree with is the idea that one can write code 
> expecting something is passed by value, and then have the 
> compiler later switch it to a reference. `in` means by value in 
> all code today. The fact that we tried -preview=in on a bunch 
> of projects and they "didn't break" is not reassuring.

Well, it is common for compilers (e.g. Ada/SPARK) to optimize 
by-value as a reference, but it should not be observable.

You could get around this by making the by-value parameter 
transfer "no-alias" with associated undefined behaviour (or 
"__restricted__" in C++ as Kinke pointed out). This would be 
great actually, except...

"in" looks very innocent to a newbie so it should have simple 
semantics... Advanced features ought to look advanced (at least 
more advanced than "in" or "out").

"in", "out", "in out" should be as simple to use as in SPARK, but 
that is difficult to achieve without constrained semantics (which 
would involve a lot more than a simple DIP). SPARK's approach to 
this looks really great though, but I've never used SPARK so I 
can't speak from experience. But, it is the kind of semantics 
that makes me more eager to give it a spin, for sure.

It might be helpful to play a bit with languages like Chapel and 
SPARK to get ideas.