www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's happening with the `in` storage class

reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Jun 08 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 08 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jun 08 2018
next sibling parent reply SonicFreak94 <sonicfreak94 hotmail.com> writes:
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 with the intention to write.
Jun 08 2018
parent Vijay Nayar <madric gmail.com> writes:
On Saturday, 9 June 2018 at 02:38:14 UTC, SonicFreak94 wrote:

 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 with the intention to write.


100% agreed.

I always found "in" to be consistent with what I view as one of 
D's core philosophies, that the simple thing should be the right 
thing.  For example, when you have a class parameter, it is 
automatically passed by reference without any other special 
considerations by the programmer.

To me, "in" has been a shorthand to communicate my desire to make 
sure that the parameter is treated strictly as an input, and not 
modified in any way or having ways to pass its reference to 
others who may then modify it.

Where I may be doing something wrong, a helpful message from the 
compiler is welcome.
Jun 12 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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'.
Jun 08 2018
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Jun 08 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, June 08, 2018 22:00:02 Ali Çehreli via Digitalmars-d wrote:

 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'.


Yes, but the exact mening of scope has never been clear. Plenty of folks
have made assumptions about what it meant, but it was never actually
defined. Now that it is defined with DIP 1000, it seems like pretty much
everyone trying to use it has a hard time understanding it at first (at
least beyond the really simple cases). So, I think that the odds that in is
going to have been used correctly in general are not great. The other issue
is that many folks seem to use in simply because they like the idea that
it's the opposite of out, or they saw others use it and thus decided to
used. While plenty of folks have understood it to mean const scope, a
surprisingly large number of folks seem to have not understood that, and
their code will break if in actually means const scope with -dip1000.

Now, -dip1000 is already going to be breaking code in a number of cases even
without considering the name mangling issues (e.g. auto will end up now
being inferred as scope in some cases). So, it could be argued that it's
going to break code anyway, and thus we might as well just let code that
uses in break if it doesn't actually work with scope, but I think that it's
pretty clear that far more code will break if in really means const scope
than if it stays as const.

An alternative would be to add some kind of deprecation warning that
indicates that in is going to become const scope and that that particular
piece of code will break once it does, but since it can't be both scope and
not scope at the same time, I expect that anyone making such code work with
scope would be forced to change in to const scope anyway, since if they
don't, the changes to make it work with scope wouldn't work until in
actually meant scope.

- Jonathan M Davis
Jun 09 2018
next sibling parent Yuxuan Shui <yshuiv7 gmail.com> writes:
On Saturday, 9 June 2018 at 07:56:08 UTC, Jonathan M Davis wrote:

 Now that it is defined with DIP 1000, it seems like pretty much 
 everyone trying to use it has a hard time understanding it at 
 first (at least beyond the really simple cases).


It might have been because that the DIP is written in a somewhat 
confusing way.


 - Jonathan M Davis
Jun 09 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Saturday, 9 June 2018 at 07:56:08 UTC, Jonathan M Davis wrote:

 Yes, but the exact mening of scope has never been clear. Plenty 
 of folks have made assumptions about what it meant, but it was 
 never actually defined. Now that it is defined with DIP 1000, 
 it seems like pretty much everyone trying to use it has a hard 
 time understanding it at first (at least beyond the really 
 simple cases).


I don't think dip1000 changes meaning of scope, it only provides 
language rules to check that scoping is honored. I suppose the 
problem (which wasn't quite formulated by the way) is with the 
code that is correct (honors scoping), but is not compatible with 
dip1000 checks. Code that is not correct shouldn't compile really.
Jun 10 2018
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 9 June 2018 at 05:00:02 UTC, Ali Çehreli wrote:

 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


Ditto. `in == const scope` was has always been my understanding.
Jun 09 2018
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Jun 08 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 08 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
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
Jun 08 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 09 2018
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Saturday, 9 June 2018 at 07:26:02 UTC, Walter Bright wrote:


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


If that's how you feel then I clearly don't share your values.  
To me, cleaning up the unimplemented, half-implemented, and 
poorly implemented features of D is very important.  I would like 
to be able to use D professionally, and you make difficult it to 
advocate for D with a straight face when you're willing to 
tolerate this kind of sloppiness in the language definition and 
implementation.

All I'm asking for is a thoughtful decision, and don't appreciate 
the implication that I'm wasting my time.

Mike
Jun 09 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
 Walter do you have a long term plan for `in`?

If not, is there a dependency(s) that when completed that would make you 
feel more comfortable talking about it constructively?
Jun 09 2018
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 9 June 2018 at 07:40:08 UTC, Mike Franklin wrote:

 On Saturday, 9 June 2018 at 07:26:02 UTC, Walter Bright wrote:


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


 If that's how you feel then I clearly don't share your values.  
 To me, cleaning up the unimplemented, half-implemented, and 
 poorly implemented features of D is very important.  I would 
 like to be able to use D professionally, and you make difficult 
 it to advocate for D with a straight face when you're willing 
 to tolerate this kind of sloppiness in the language definition 
 and implementation.

 All I'm asking for is a thoughtful decision, and don't 
 appreciate the implication that I'm wasting my time.

 Mike


Seems to be alot of fundamental problems with D that Walter and 
Andrei say are "unimportant".

Some of the things I've seen to be neglected are `shared`, `in`, 
broken import in-variance, tooling, community, compiler 
brittleness.  The results of the dlang survery seem to have been 
ignored.  Features like "tuples", "named parameteers", 
"interpolated strings" were highest on the list but I don't see 
any call to action.  In fact I see quite a lot of resistance.

It seems that Walter and Andrei are forcing D into an "end of 
life" stage where language improvements and cleanup are 
consistently rejected, even ones with high benefit/const ratio. I 
hope I'm wrong though. On the "technical scale" D is a top 
contender, but if it stagnates it will be supplanted by new 
languages, maybe even ones that already exist.
Jun 09 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 10/06/2018 6:56 AM, Jonathan Marler wrote:

 Some of the things I've seen to be neglected are `shared`, `in`, broken 
 import in-variance, tooling, community, compiler brittleness.  The 
 results of the dlang survery seem to have been ignored.  Features like 
 "tuples", "named parameteers", "interpolated strings" were highest on 
 the list but I don't see any call to action.  In fact I see quite a lot 
 of resistance.


shared, will be a real pain, W&A are not in the same boat as to what 
they want it to do.

in, agreed pain currently, give it time (too recent).

import in-variance, dunno.

dlang survey, its being worked on as far as I'm aware.

tuples needs a DIP, but that'll be a pain to get in and since it can be 
done library it can be argued against.

named parameters, we have one DIP in queue (although I consider it 
not-ready) and I do have my own which is nearly there[0].

interpolated strings, Yeah we are not gonna get that.

[0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md
Jun 09 2018
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:

 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.


My $0.02 is that:

* I've always used `in` knowing it meant `scope const`, that 
`scope` wasn't defined, and that one day it would be, possibly 
changing the meaning of my code.

* Currently one has to pass `-dip1000` to get `scope` to do 
anything. This is opt-in. Any breakages would also be opt-in. I 
don't think breakage considerations are important here.

* As Adam pointed out, code that fails to compile that uses `in` 
_and_ `-dip1000` has about a 99.9999% chance of being buggy 
anyway. Yay for buggy code that no longer compiles!

* If `in` means the same as `const`, then this is yet another 
ugly wart that only exists because of historical reasons, and 
makes D harder to teach, or even to justify. "Yes, but..." isn't 
a good look.

I mean, we can't even currently use `-dip1000` in a unittest 
build since that breaks Phobos.
And searching throught github.com is revealing:

https://github.com/search?q=filename%3Adub.sdl+dip1000
https://github.com/search?q=filename%3Adub.json+dip1000

15 hits in all. I say keep `in` as it is. Anybody who was using 
it should have known they were playing with a bleeding edge 
not-yet-implemented feature anyway.

Atila
Jun 11 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/11/18 7:48 AM, Atila Neves wrote:

 * Currently one has to pass `-dip1000` to get `scope` to do anything. 
 This is opt-in. Any breakages would also be opt-in. I don't think 
 breakage considerations are important here.


Just on this point, there is nothing "opt in" about dip1000. Either all 
the code you use is compiled with dip1000, or it's not. Since it alters 
symbol names, you can't link a library that uses dip1000 against one 
that doesn't, and expect it to work.

For a while, phobos was partly compiled with dip1000 and it was a disaster.

There is going to be a cutoff date at some point, where Phobos is 
compiled with dip1000, and then you are going to have to use an earlier 
compiler to "opt out" of it.

Unless, of course, we can work out how to deal with the symbol name 
adjustments.

-Steve
Jun 11 2018
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/11/18 9:11 AM, Steven Schveighoffer wrote:

 For a while, phobos was partly compiled with dip1000 and it was a disaster.


I should say, this was only for unittests. Normal release was done 
without dip1000.

-Steve
Jun 11 2018