Release D 2.094.0

[Seb]

On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote:
> On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote:
>> On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote:
>>> [...]
>>
>> Yes we have a 3rd way. Because `auto ref` just doesn't cut it 
>> for most usages, and `-preview=rvaluerefparam` never worked.
>>
>> You can have a look at the full discussion in the PR that 
>> introduced it (dmd#11000).
>> I try to summarize a few arguments in favor of it here: 
>> https://github.com/dlang/dmd/pull/11000#issuecomment-674498704
>>
>> As you can see from the discussion, it's not really something 
>> that was quickly merged, but the results of months of work. So 
>> while it might seems "ridiculous" to you, I'd appreciate if 
>> you could take the time to read through the discussion, as 
>> well as taking a look at Herb Sutter's presentation which was 
>> linked.
>>
>> The key takeaway from that presentation is that instead of 
>> having the users specify *how* to pass the parameter, they 
>> should specify what is the parameter's semantic. In our case, 
>> input (in), output (out), or input/output (ref).
>>
>> I'm not aware of a situation where you want to use `auto ref` 
>> on a parameter without `const` (or `const` semantic), because 
>> if you intend to modify the parameter, you need to be sure 
>> whether it's `ref` or not. I'm aware some people use it for 
>> forwarding but this has its own set of problem.
>
> I've read the discussion but skipped the presentation. All I 
> see is Atila expressing distaste for the compiler choosing how 
> to pass values, and no explicit sign-off from either Walter or 
> Atila before it was merged.
>
> My objection is not to `in`'s new behaviour (although having 
> something that functions similarly to auto ref but in subtly 
> different ways is not good language design, IMO). My objection 
> is that we have a major change to a language feature, that was 
> merged without the apparent blessing of either of the two 
> people who are supposed to be the gatekeepers for these 
> decisions, and without a DIP (yes, it is behind -preview, but 
> that implies that this will eventually make it into the 
> language proper). That is what I am calling "ridiculous". If W 
> or A did approve it and I just wasn't aware, then I apologize 
> and retract my objection.

You seem to have a wrong understanding of -preview. It doesn't 
even pretend to be an officially approved feature. I think this 
is what's been causing the confusion.

Preview flags are what other compilers call "experimental". In 
fact, -preview is intended to predate a DIP or formal approval in 
other ways, because if you don't know the impact of a feature or 
usefulness, it's very hard to make an informed decision.

This has the nice side effect that sometimes it becomes clear 
during an implementation that the idea as is unfeasible.

> implies that this will eventually make it into the language 
> proper

No, it doesn't.