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.

On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote:
> On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote:
>> If W or A did approve it and I just wasn't aware, then I apologize and retract my objection.
>
> https://github.com/dlang/dmd/pull/11000#issuecomment-675605193

As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila".

On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote:
> On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote:
>> 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.

Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?

On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote:
> On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote:
>> [...]
>
> Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?

Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed).

There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee.

On Thursday, 1 October 2020 at 21:19:02 UTC, Seb wrote:
> On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote:
>> On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote:
>>> [...]
>>
>> Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?
>
> Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed).
>
> There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee.

Okay, fair enough. Looks like I was mistaken and thought -preview implied that the feature will be moved out from under the switch after a certain number of releases (as the word "preview" means an early look at something that will be released in the future).

On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote:
> On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote:
>> On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote:
>>> On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote:
>>>> [...]
>>>
>>> Yay! "-preview=in" is beyond epic!
>>
>> I like epic things. What does it do? :D
>
> Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in
> The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters.

Thanks for the clarification

On 10/1/20 5:08 PM, Meta wrote:
> On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote:
>> On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote:
>>> If W or A did approve it and I just wasn't aware, then I apologize and retract my objection.
>>
>> https://github.com/dlang/dmd/pull/11000#issuecomment-675605193
> 
> As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila".

That is correct, thanks for clarifying. Related: thanks Mathias for working on improving the status quo in function parameter modifiers. Any shake of that rusty nail is likely to improve matters.

On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote:
> Glad to announce D 2.094.0, ♥ to the 49 contributors.
>
> This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics.
>
> http://dlang.org/download.html
> http://dlang.org/changelog/2.094.0.html
>
> -Martin

```
$ curl -fsS https://dlang.org/install.sh | bash -s dmd
Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz
######################################################################## 100.0%
gpg: Signature made Tue Sep 22 18:58:37 2020 KST
gpg:                using RSA key 3AAF1A18E61F6FAA3B7193E4DB8C5218B9329CF8
gpg: Can't check signature: No public key
Invalid signature http://downloads.dlang.org/releases/2.x/2.094.0/dmd.2.094.0.osx.tar.xz.sig
```

I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler?

On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote:
> I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler?

This might have come off a bit rude, apologies for that.

That being said, the solution seemed to be to run the `update` command on the script. It wasn't really obvious though.

On Monday, 5 October 2020 at 09:17:13 UTC, Andrej Mitrovic wrote:
> On Monday, 5 October 2020 at 03:27:22 UTC, Andrej Mitrovic wrote:
>> I'm not sure if it's related to https://issues.dlang.org/show_bug.cgi?id=21226. But how many people will be turned away not being able to install the compiler?
>
> This might have come off a bit rude, apologies for that.
>
> That being said, the solution seemed to be to run the `update` command on the script. It wasn't really obvious though.

Well, the "signature" topic is a constantly reoccurring issue and you can find plenty complains in the news group / forum... some examples:
- https://forum.dlang.org/post/mailman.3930.1592291554.31109.digitalmars-d-bugs@puremagic.com
- https://forum.dlang.org/post/mailman.2853.1587904820.31109.digitalmars-d-bugs@puremagic.com

- https://forum.dlang.org/post/fnaizrmuezxobtxlauci@forum.dlang.org
- https://forum.dlang.org/post/lwsekmmdlmfkhkahmucu@forum.dlang.org
- https://forum.dlang.org/post/szvratfzlyfbjeumabiy@forum.dlang.org
- https://forum.dlang.org/post/hpdxzlxwofpktlaaokuz@forum.dlang.org


I made a quick enhancement proposal as suggested by Seb before / here
- https://github.com/dlang/dlang.org/pull/2817#pullrequestreview-425842582
... my pull request was merged but later reverted again:
- https://github.com/dlang/installer/pull/457
- https://github.com/dlang/installer/pull/302

Seb promised to work on it... whenever he finds the need and time for it. Mybe someone else can continue / implement / drive this "auto update" topic...

regards