in; scope; scope ref; DIP1000; documentation

Mathias LANG geod24 at gmail.com
Fri Aug 28 09:19:18 UTC 2020


On Thursday, 27 August 2020 at 18:49:19 UTC, James Blachly wrote:
> Peeling off from Mathias Lang's thread in General about making 
> 'in' useful, for some novice questions:
>
>
> 1. The thread involves 'in' qualifier. Documentation 
> (https://dlang.org/spec/function.html#param-storage) indicates 
> that `in` is defined as `scope const` and should not be used as 
> it is not implemented. **Is this [fact and recommendation] 
> still true?**

I have a PR to update the documentation: 
https://github.com/dlang/dlang.org/pull/2845
I got feedback on it, just didn't have time to complete / finish 
it, will come back to it soon.

> Is "scope ref" documented somewhere specifically? I found 
> https://dlang.org/spec/function.html#scope-parameters which 
> discusses the use of `scope` with ref type parameters, but the 
> example given is pointer-based. Is it correct that `scope ref 
> T` behaves the same as `scope T*` ?
>
> Regarding `scope` more generally, DIP1000 shows as "superseded" 
> -- **can I still rely on this document for guidance?** We have 
> a `-dip1000` flag but a superseded DIP. The discordance is 
> extremely confusing.

It is, for users and compilers developers alike. We're still 
waiting for Walter to write down the docs on that. If you look in 
the forums / PRs, you'll see that it's the most common feedback.

> I am glad D is iterating quickly and improving on safety, but I 
> have found that documentation may not well recent changes in 
> this area. Consequently I am reluctant to use (newer) features 
> related to memory safety. If this is all comprehensively 
> documented somewhere please let me know!

We have a policy that every language change should come with a 
spec PR. It has improved documentation drastically, but there's 
still a way to go.

I hope the aforementioned PR will clarify the status of `in`. I'm 
currently focusing on making sure it works properly everywhere 
before the next release (in 1 or 2 weeks), hence why fixing that 
PR has taken the back-seat (the website gets auto-updated, so 
even if the PR doesn't make the deadline, it'll be deployed as 
soon as it gets merged).


More information about the Digitalmars-d-learn mailing list