-preview=in might break code

[Andrei Alexandrescu]

On 10/3/20 8:09 AM, Mathias LANG wrote:
> On Saturday, 3 October 2020 at 05:02:36 UTC, Andrei Alexandrescu wrote:
>> [...]
>>
>> Wait a SECOND! Are we really in the market of developing and deploying 
>> language features that come unglued at the slightest and subtlest 
>> misuse? We most certainly shouldn't.
> 
> I agree. What I don't agree with is that this aliasing is a "slight and 
> subtle misuse". I went through the 64 projects and their dependencies 
> that are on Buildkite, and didn't see a hint of this pattern emerging. 
> Nor did it in any other code I've surveyed in the almost 5 months the PR 
> was open.

First off, thanks for engaging. Having taken a look at existing projects 
is a wise thing to do. There are a few counterpoints here:

* Proving a negative is inherently difficult.

* It's difficult to look at millions of lines of code, much of which is 
templated (and so can be subject to problems in the future), and make an 
assessment. (Clearly it's very impressive that you did.) That is not a 
guarantee and does not cover future uses, however.

* The fallacy of numbers comes to mind. You wouldn't want to introduce, 
for example, some subtle concurrency problem on account on not having 
seen it in existing projects.

* This has been discussed in C++ circles a number of times, and aliasing 
has always been a concern. If /C++/ deemed that too dangerous... <insert 
broadside>. A much more explicit solution has been implemented in 
https://www.boost.org/doc/libs/1_66_0/libs/utility/call_traits.htm.

>> I sincerely congratulated Mathias and the other participants for 
>> working on this. It's an important topic. Knowing that all those 
>> involved are very good at what they do, and without having looked 
>> closely, I was sure they got something really nice going that avoids 
>> this absolutely blatant semantic grenade. And now I see this is 
>> exactly it - we got a -preview of a grenade. How is this possible? How 
>> can we sleep at night now?
>>
>> Again: take a step back and reconsider, why did this pass muster?
> 
> Maybe because the people that want to use this actually know this is 
> nowhere near as big of an issue as some people try to make it look.

Sorry if it looks like I'm pushing an agenda here - I most certainly am 
not. I'm acting on the perception that this looks distinctly like one of 
the mistakes of the past that now we're wondering how they made it and 
how to undo them. At the very minimum a lot more scrutiny is necessary.

> Perhaps you don't know this, but the very first implementation, the one 
> I had when I opened the PR on April 3rd actually always used `ref`. It 
> had quite a few issues. @Kinke suggested an alternative, and that 
> alternative brought many benefits with it, for a very minor downside, 
> which can easily be mitigated: if your function's semantic really depend 
> on mutation through an alias propagating (or not) to an `in` parameter, 
> then you can use `__traits(isRef, paramname)` to check it.
> Later on, on July 31st, I brought the topic to the forum, which pressed 
> on another suggestion @Kinke has made, using the full function type 
> instead of just the parameter type. At the time, you also made mention 
> of this issue, and it was considered.

Thank you for the context.

> I wonder, did you try to adapt one of your projects to `in` ? Not merely 
> throwing the switch, but also adding a couple `in` here and there, were 
> it makes sense.

I have no doubt it will work in many instances. What I'm worry about is 
that when it doesn't, the user has very little indication and tooling to 
help with the most puzzling (and platform-dependant!) behavior.

> Not that this `-preview` is the only one that has ever been usable from 
> release day (perhaps `markdown` was as well, but it only affected 
> documentation generation). All the other previews would fail on your 
> project because druntime and Phobos were never adapted after the switch 
> was merged. `-preview=in` not only works with druntime/phobos, but many 
> libraries from Buildkite were also adapted to work with or without it 
> (https://github.com/dlang/dmd/pull/11632). I was expecting this would 
> increase user engagement, allow to gather feedback, use cases, and lead 
> to a healthy discussion, just like it allowed to refine the 
> implementation. But I wasn't expecting FUD to be spread over a 
> `-preview` before people even tried it.

Again, indeed sorry if it looks I'm trying to spread FUD and thanks for 
engaging. All I'm doing is to try to be sensible.