On Friday, 29 March 2019 at 02:40:43 UTC, Andrei Alexandrescu wrote:
> On 3/28/19 10:03 PM, Jonathan Marler wrote:
>> On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:
>>> On 3/28/19 2:12 PM, ag0aep6g wrote:
>>>> [...]
>>>
>>> We've been worrying too much about changing things.
>>>
>>> On any given issue, even those that widely agreed to be clowny, two factions emerge. One advocates change and the other advocates against code breakage. Interestingly the factions are different depending on the issue, i.e. a given person may be in favor of change in one matter and in favor of backwards compatibility in another. At any rate, the result is years-long stalemate and trench warfare on the slightest problems.
>>>
>>> [...]
>> 
>> This is a complete 180 from what you were saying a year ago. What happened?
>
> "I'd rather be right than consistent." -- Winston Churchill

A good rule to live by and be aware of as many tend to stick to their guns rather than admitting they're not perfect.

In any case I am very pleased to see this new attitude. I was just genuinely wondering what caused it.

On Friday, 29 March 2019 at 02:40:43 UTC, Andrei Alexandrescu wrote:
> On 3/28/19 10:03 PM, Jonathan Marler wrote:
>> On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:
>>> On 3/28/19 2:12 PM, ag0aep6g wrote:
>>>> [...]
>>>
>>> We've been worrying too much about changing things.
>>>
>>> On any given issue, even those that widely agreed to be clowny, two factions emerge. One advocates change and the other advocates against code breakage. Interestingly the factions are different depending on the issue, i.e. a given person may be in favor of change in one matter and in favor of backwards compatibility in another. At any rate, the result is years-long stalemate and trench warfare on the slightest problems.
>>>
>>> [...]
>> 
>> This is a complete 180 from what you were saying a year ago. What happened?
>
> "I'd rather be right than consistent." -- Winston Churchill

Kudos!

On 29.03.19 02:55, Walter Bright wrote:
> Ranges don't need to be assignable. ForwardRanges need to supply a save(), which means copy construction, not assignment.

Issue 18657 is all about RefRange not being assignable (without nasty surprises). Changing Phobos to avoid assignment of ranges will fix the issue.

All the mighty talk about "generality creep" and "first principles" is besides the point. You agree with making changes all over Phobos. You just don't like the weird `move` code. That's okay. I agree that fixing the issue with constructors is nicer.

[...]
>> How does RefRange.save need fixing?
> 
> I thought you wrote that copy construction would make RefRange work?

Implementing the `save` methods of higher ranges that way makes them compatible with RefRange, because they no longer call RefRange.opAssign.

RefRange.save is fine as it is (w.r.t issue 18657).

On 29/03/2019 03:40, Andrei Alexandrescu wrote:
> On 3/28/19 10:03 PM, Jonathan Marler wrote:
>> On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:
>>> We've been worrying too much about changing things.
>>>
>>> [...]
>>
>> This is a complete 180 from what you were saying a year ago. What happened?
> 
> "I'd rather be right than consistent." -- Winston Churchill

I too applaud this insight. As many may know, I'm helping a company move away from a fossilized language and it has decided to make its business depend on D. Although reacting to deprecations won't always come convenient, distributing the cost of evolution is much more preferable than making the massive investment they are in for now. So I'm sure they appreciate seeing these signs of D staying dynamic, averting sedimentation.

Bastiaan.

On 3/28/19 10:47 PM, Mike Franklin wrote:
> On Thursday, 28 March 2019 at 20:02:17 UTC, Andrei Alexandrescu wrote:
> 
>>> I'm still wondering, though, how we're going to drop druntime while
>>> still maintain backward compatibility.  Or how we could skip the startup
>>> code that invokes module ctors and packages command-line args into
>>> string[].  It would be awesome if we could pull this off, but I don't
>>> currently see how we could do it without major breakage.
>>
>> Compiler flag.
> 
> D is so powerful, this can also be done in other ways as well.
> 
> As Andrei alluded to in another post, we just need to embrace addition.  Keep the existing logic path in place, and create a new one that does what we want it to do.  With design-by-introspection, and probably a number of other awesome D facilities, the correct logic path can be chosen at compile-time based on what the user has declared in their code.

*nod*

> Another idea is allowing "module inheritance" for lack of a better term.  Users can "inherit" from an "abstract" module but override the default startup and shutdown logic.  Perhaps we refactor the current logic path to inherit from this "abstract" module but add all of the existing startup and shutdown implementation as overrides.  The compiler is then modified to "inherit" from that module by default.  Users that don't want the default can "inherit" from the "abstract" module and provide their own implementation.

Yah, I actually had even code for an idea - after each module is loaded, the following code is automatically injected at the end of it:

mixin(__onImportedModule(__MODULE__));

This is evaluated in the context of the importer (not imported), an essential detail. By default of course the function returns the empty string.

This allows user code to add things like serialization, factories and other introspection-based utilities automatically upon import.

On 3/28/19 9:26 PM, Mike Franklin wrote:
> On Thursday, 28 March 2019 at 20:14:19 UTC, Andrei Alexandrescu wrote:
>> On 3/28/19 3:12 PM, H. S. Teoh wrote:
>>> I applaud this direction, but let's not kid ourselves
>>> that this is going to happen overnight.
>>
>> Or at all. The entire effort would require three strong like-minded engineers, and I don't know them.
> 
> Or a team of subordinate apprentice/junior engineers (who have demonstrated sufficient potential) working under the mentorship of a master who is willing to make an investment.

This is a lot more difficult to set up than it seems.

One reason is that surprisingly few of the contributors come here to learn, to acquire knowledge. Most come to dispense. I spent long times reviewing pull requests in our community, calibrated to the reviews standards at Facebook (however controversial, they have an impressive software engineering force). There, the code review process is locked in a virtuous circle: you get good reviews that help you improve, and you'd be motivated to give good reviews to improve others'.

Here, my reviews were more often than not met with hostility.

As a pattern, a reviewer would be more willing to write the code once and then defend it in its current state, rather than improve it through review. In a few extreme cases, people flat out told me they'll abandon the PR if I don't take it as it is. Larger disagreements on matters of architecture and design were often taken as personal offenses. Of course, retaliation was soon to follow. My own ideas and code would be met with suspicion and I'd need to push them uphill instead of them being encouraged and improved, which provided disincentive for trying any creative work. I'd be routinely followed on github and countered at whatever I'd do or say. Of course this happened to Walter even more, and the only therapy we got was commiseration via the occasional email titled "Somebody shoot me" or similar, and containing just a link to a github comment.

I'd wake up in the morning for days, then weeks and months, with one thought: "I have so many things to do today, and I like none of them." The irony! Here I was, independent, working for myself on whatever I dreamed of. Yet this was worse than the worst jobs I've ever had. How did I get into this situation? I think it has to do with a simple reality - I was trying to mentor people who didn't want to be mentored.

So I think it would be difficult to establish a master/mentee dynamics.

On 3/29/19 9:57 AM, Andrei Alexandrescu wrote:
> As a pattern, a reviewer would be more willing to write the code once 

s/reviewer/author/

On 29.03.19 08:41, ag0aep6g wrote:
> I agree that fixing the issue with constructors is nicer.

PR to change my `move`s to constructor calls:

https://github.com/dlang/phobos/pull/6939

On Friday, 29 March 2019 at 13:05:31 UTC, Andrei Alexandrescu wrote:
> Yah, I actually had even code for an idea - after each module is loaded, the following code is automatically injected at the end of it:
>
> mixin(__onImportedModule(__MODULE__));
>
> This is evaluated in the context of the importer (not imported), an essential detail. By default of course the function returns the empty string.
>
> This allows user code to add things like serialization, factories and other introspection-based utilities automatically upon import.

Jean-Louis argued for that overall feature at last year's DConf, and I also agree. Such a feature would be useful for a lot of things, although it's one of those "with great power comes great responsibility" kind of features.

On Friday, 29 March 2019 at 13:57:57 UTC, Andrei Alexandrescu wrote:
> Here, my reviews were more often than not met with hostility.
>
> As a pattern, a reviewer would be more willing to write the code once and then defend it in its current state, rather than improve it through review. In a few extreme cases, people flat out told me they'll abandon the PR if I don't take it as it is.

Where I work, we're trying our best to do design reviews before starting large implementations and to seek reviewer feedback throughout the process. We do this because it seems clear that after the code is already written and after several days' to weeks' worth of effort has gone into a feature, the cost to making fundamental design changes is as great as it's going to get, and developer attachment to the existing code as well as frustration with the reviewer is high, especially when the reviewer asks for fundamental design changes.

And this, to pivot to another debate we had recently, is exactly why it's a counterproductive approach to do DIP reviews only at the end.