https://github.com/dlang/druntime/pull/1748/files

Why is `in` no longer the same as `const ref`?

On Sunday, 29 January 2017 at 11:49:19 UTC, Nordlöw wrote:
> https://github.com/dlang/druntime/pull/1748/files
>
> Why is `in` no longer the same as `const ref`?

Correction:

Why is `in` no longer the same as `const scope`?

On 1/29/2017 3:50 AM, Nordlöw wrote:
> Why is `in` no longer the same as `const scope`?

Because it was unchecked and largely unimplemented. I was afraid that by checking it, too much code would break.

On Monday, 30 January 2017 at 00:26:27 UTC, Walter Bright wrote:
> On 1/29/2017 3:50 AM, Nordlöw wrote:
>> Why is `in` no longer the same as `const scope`?
>
> Because it was unchecked and largely unimplemented. I was afraid that by checking it, too much code would break.

Will we make them equal in the long run? So much shorter to read.

On Sunday, January 29, 2017 16:26:27 Walter Bright via Digitalmars-d wrote:
> On 1/29/2017 3:50 AM, Nordlöw wrote:
> > Why is `in` no longer the same as `const scope`?
>
> Because it was unchecked and largely unimplemented. I was afraid that by checking it, too much code would break.

Which is why I've been arguing against anyone using in for years, but some folks really liked how it was a parallel of out and used it anyway. Some understood what scope was at least theoretically supposed to mean and were willing to deal with the consequences if and when scope were actually implemented beyond delegates, but most just used it without that understanding.

Personally, I think that effectively having an alias for two attributes in a single attribute is a confusing design decision anyway and think that it was a mistake, but we've had folks slapping in on stuff for years with no enforcement, and flipping the switch on that would likely not be pretty.

- Jonathan M Davis

On 1/29/2017 9:50 PM, Nordlöw wrote:
> Will we make them equal in the long run? So much shorter to read.

I know it's shorter. I'd like to do it too, we'll have to see.

On Monday, 30 January 2017 at 08:02:12 UTC, Walter Bright wrote:
> On 1/29/2017 9:50 PM, Nordlöw wrote:
>> Will we make them equal in the long run? So much shorter to read.
>
> I know it's shorter. I'd like to do it too, we'll have to see.

Can it be enabled for -dip1000 flag?
Doc was pretty clear on what it was suppose to do and people kinda knew that scope was not finished.

Having it turned on for dip flag will allow some testing of the existing code. I would like to have in's intended semantic finally implemented.

On 1/30/2017 12:42 AM, Radu wrote:
> Can it be enabled for -dip1000 flag?
> Doc was pretty clear on what it was suppose to do and people kinda knew that
> scope was not finished.
>
> Having it turned on for dip flag will allow some testing of the existing code. I
> would like to have in's intended semantic finally implemented.

I'd rather do one thing at a time.

On Monday, 30 January 2017 at 06:38:11 UTC, Jonathan M Davis wrote:
> Personally, I think that effectively having an alias for two attributes in a single attribute is a confusing design decision anyway and think that it was a mistake, but we've had folks slapping in on stuff for years with no enforcement, and flipping the switch on that would likely not be pretty.
>
> - Jonathan M Davis

I've always thought of 'in' as a visual shorthand for "this parameter doesn't care whether you give it a deep copy or a shallow reference", personally.

On Monday, 30 January 2017 at 00:26:27 UTC, Walter Bright wrote:
> I was afraid that by checking it, too much code would break.

Code that was using it improperly was *already* broken. Now, the compiler will simply tell them, at compile time, why instead of letting it silently accept undefined behavior.