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

@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?

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

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.

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

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.

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

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.

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

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