What's the purpose of the 'in' keyword ?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sun May 27 16:00:15 UTC 2018


On Sunday, May 27, 2018 16:28:56 Russel Winder via Digitalmars-d-learn 
wrote:
> On Sun, 2018-05-27 at 13:10 +0000, Adam D. Ruppe via Digitalmars-d-learn
>
> wrote:
> > On Sunday, 27 May 2018 at 13:02:23 UTC, loloof64 wrote:
> > > What's the purpose of this 'in' keyword ? I could not process a
> > > good Google request to get an answer.
> >
> > It means you are taking the parameter in to look at, but not
> > modify or store.
> >
> > Basically "const". (well, for now, literally "const" but that can
> > change with other details)
>
> Is there an easy set of "rules" as to when to use 'const' and when to use
> 'in'?
>
> In a situation where there are multiple ways of expressing the same
> concept there needs to be idioms to guide people to do the right thing in
> a given context.

Honestly, I'd suggest that folks never use in at this point. There's zero
benefit to it. In principle, in was supposed to be const scope, but scope
has never really done anything for anything other than delegates, so there
has been no reason to use it over const. However, many folks seem to like it
based on the idea that it was the opposite of out - and some folks used it
based  n what they expected scope to end up meaning whenever it finally got
implemented for more than just delegates. Either way, it didn't actually buy
them anything as long as scope has done nothing.

Now with DIP 1000, scope is actually starting to mean something, but there's
the concern that enabling scope for all of the places that in was used would
break a lot of code. So, the spec now says that in means const rather than
const scope, and as I undertand it, for the most part, the compiler doesn't
treat it as scope anywhere aside from a a few buggy cases (even when
-dip1000 is used). Some folks are not happy about that, and the situation
may yet change (heck, we haven't even figured out how to switch to -dip1000
being the default without breaking everyone in the process yet - e.g. it's
not ABI compatible with code that's not compiled with -dip1000, because it
mangles differently). So, we can't really say what in is going to end up
meaning when the dust settles.

Ultimately, it may permanently just be const, or it may end up actually
being const scope. But it's never actually bought you anything over using
const (other than being shorted), and if it does end up becoming const
scope, you're almost certainly going to have to fix a lot of the code that
you wrote using in. So, I really don't think that it's a good idea to use in
at all, but there are definitely folks who disagree with me, some of whom
very much hope that it ends up meaning const scope and who want it to break
their code if/when it does if there's any kind of escaping in their code -
though given how confusing -dip1000 seems to be for many folks, I seriously
question that much code using in would just work if it's changed to properly
mean const scope or that all that many programmers using in understand scope
well enough to use it correctly.

- Jonathan M Davis



More information about the Digitalmars-d-learn mailing list