Jump to page: 1 2 3
Thread overview
What's happening with the `in` storage class
Jun 09, 2018
Mike Franklin
Jun 09, 2018
Walter Bright
Jun 09, 2018
Adam D. Ruppe
Jun 09, 2018
SonicFreak94
Jun 13, 2018
Vijay Nayar
Jun 09, 2018
Walter Bright
Jun 09, 2018
Ali Çehreli
Jun 09, 2018
Jonathan M Davis
Jun 09, 2018
Yuxuan Shui
Jun 10, 2018
Kagamin
Jun 09, 2018
Nicholas Wilson
Jun 09, 2018
Mike Franklin
Jun 09, 2018
Walter Bright
Jun 09, 2018
Mike Franklin
Jun 09, 2018
Walter Bright
Jun 09, 2018
Mike Franklin
Jun 09, 2018
rikki cattermole
Jun 09, 2018
Jonathan Marler
Jun 10, 2018
rikki cattermole
Jun 11, 2018
Atila Neves
June 09, 2018
See https://dlang.org/spec/function.html#parameters

I also noticed Walter removed `in` in this PR:  https://github.com/dlang/phobos/pull/6561

Should it be deprecated (not necessarily removed) to guide users towards a more consistent and idiomatic usage of the language?  Also, if there are fewer usages, it will make it much easier to redefine `in` to something useful in the future.

Mike
June 08, 2018
On 6/8/2018 6:02 PM, Mike Franklin wrote:
> Should it be deprecated (not necessarily removed) to guide users towards a more consistent and idiomatic usage of the language? Also, if there are fewer usages, it will make it much easier to redefine `in` to something useful in the future.


'in' is supposed to mean 'scope const'. But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.

So I recommend incrementally replacing it as you see it with 'scope const' and fixing anything that breaks.
June 09, 2018
On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
> But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.


It isn't going to break anything. It is going to *correctly diagnose already broken code*.

That's a significant difference. Real world D users don't like broken code, but they DO like the compiler catching new bugs that slipped by before.
June 09, 2018
On Saturday, 9 June 2018 at 02:17:18 UTC, Adam D. Ruppe wrote:
> On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
>> But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.
>
>
> It isn't going to break anything. It is going to *correctly diagnose already broken code*.
>
> That's a significant difference. Real world D users don't like broken code, but they DO like the compiler catching new bugs that slipped by before.

I agree. I would rather my potentially broken code be pointed out to me rather than removing the much more concise `in` from my code. In any case, I feel as though the concept of both `in` and `out` should be fairly intuitive. `in` would be a read-only reference (C# has received this recently), and `out` is a reference with the intention to write.
June 09, 2018
On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:

> 'in' is supposed to mean 'scope const'. But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.

I think the breakage would be simple to mitigate.  Anywhere `in` is used we display a deprecation message...

"Deprecation: `in` is currently equivalent to `const`.  In v2.{whatever} `in` will be changed to `scope const`.  To keep the current semantics, replace `in` with `const`.  To silence this message change your code to `scope const` or simply ignore this message until v2.{whatever}.  See https://dlang.org/spec/function.html#parameters for more information.

... and update the documentation to explain the change.

Simple! And when v2.{whatever} comes around, we're all set with a better D.

Mike

June 08, 2018
On 6/8/2018 7:17 PM, Adam D. Ruppe wrote:
> On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
>> But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.
> 
> 
> It isn't going to break anything. It is going to *correctly diagnose already broken code*.

Not unless the caller was relying on it being 'in'.
June 08, 2018
On 06/08/2018 09:55 PM, Walter Bright wrote:
> On 6/8/2018 7:17 PM, Adam D. Ruppe wrote:
>> On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
>>> But it was never enforced, meaning that suddenly enforcing it is just going to break code left and right.
>>
>>
>> It isn't going to break anything. It is going to *correctly diagnose already broken code*.
> 
> Not unless the caller was relying on it being 'in'.

It's been clear since I've heard first about it that it meant 'scope const'.

Ali
June 08, 2018
On 6/8/2018 8:12 PM, Mike Franklin wrote:
> Simple! And when v2.{whatever} comes around, we're all set with a better D.

My goal in the short term is that Phobos is going to compile successfully with dip1000 the way it is now. It has already been deferred and deferred and deferred.
June 09, 2018
On Saturday, 9 June 2018 at 05:00:29 UTC, Walter Bright wrote:

> My goal in the short term is that Phobos is going to compile successfully with dip1000 the way it is now. It has already been deferred and deferred and deferred.

I understand that, and while you're doing that I can begin implementing the PRs to deprecate `in` or change its definition to `scope const`, or something else.

Nothing I'm proposing will, in any way, interfere with what you're doing in Phobos.  I just want a decision about what we're going to do with `in`.  I'll do the leg work.

Mike
June 09, 2018
On 6/8/2018 10:04 PM, Mike Franklin wrote:
> On Saturday, 9 June 2018 at 05:00:29 UTC, Walter Bright wrote:
> 
>> My goal in the short term is that Phobos is going to compile successfully with dip1000 the way it is now. It has already been deferred and deferred and deferred.
> 
> I understand that, and while you're doing that I can begin implementing the PRs to deprecate `in` or change its definition to `scope const`, or something else.
> 
> Nothing I'm proposing will, in any way, interfere with what you're doing in Phobos.  I just want a decision about what we're going to do with `in`.  I'll do the leg work.

Your time is valuable, too, and while I'm not going to tell you want to work on, I'd prefer something more important.

« First   ‹ Prev
1 2 3