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