Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: it's a bad idea. Why have two community reviews? Those are made with the assumption that the DIP will actually change between the reviews. No, that's not the assumption. You're conflating Community Review with Final Review. There can be multiple rounds of the former as required and only one of the latter. In a perfect scenario, no revisions are required between CR and FR. The purpose of the Final Review is to provide one final opportunity to catch any major issues that might have been missed during the CR round(s) and to allow anyone who missed the CR round(s) a final opportunity to have their say. Revisions are expected after a CR round, but not after the FR. As the documentation explains: https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Should create a DIPW process then, duck the foundation and any formalities. Which stands for DIPWalter, which simply consists of a single step where a single topic tries to convince Walter it's a bad idea. Why have two community reviews? Those are made with the assumption that the DIP will actually change between the reviews. What's the point of a "formal review" when there's just Walter talking to himself (rip Andrei). Why waste everyone's time on formalities when they obviously are irrelevant? The formal assessment isn't Walter by himself. Atila took Andrei's place in that role. There is no automatic approval. Had Atila objected to the DIP, Walter would have had to either convince him to come around to his point of view or revise the DIP to meet Atila's concerns.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 00:03:35 UTC, Jonathan M Davis wrote: On Monday, October 21, 2019 6:59:21 AM MDT Exil via Digitalmars-d-announce wrote: > This proposal is one step toward a larger goal outlined in > the > > blog post ['Ownership and Borrowing in > D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/). That's the only line that was added, no other changes were made to the core DIP from the first revision to the last. Big ducking surprise this got accepted anyways. Did you expect anything else? Given that it was Walter's DIP, and he's making the decisions, the only way that the DIP was going to change was if he were convinced that the DIP was flawed. He's been convinced of that before (e.g. the DIP that was for adding a bottom type was written by Walter, but it was rejected, because the community convinced him that it was a bad idea). I wasn't expecting any better, but I did have hope. He just wasn't convinced that this DIP was a bad idea. The "problem" this DIP is supposed to solve (per the poorly written DIP) isn't actually solved by the DIP. No answer was given to that fact. Other than the actual problem this DIP was supposed to be solved will be fixed at a later date by a separate DIP. Personally, I didn't see any problem with this DIP, since it just tightened down @safe a bit. Breaking changes, the author took no time to even try to measure how wide spread it would be. There are no benefits, the problems that are supposed to be solved with it aren't actually solved. Not to mention the problem is actually solved just by using the GC. Like you are only able to in @safe code anyways. Whether the next steps in the "larger goal" are good ones is another matter entirely, and those will be put in a DIP (or multiple DIPs) and argued on their own at some point. There's no reason for this one to be on it's own. It's useless on it's own, causes breaking changes, and who knows what the rest of the implementation might end up looking like. This is being done all prematurely. And if they're bad ideas, then hopefully he will be convinced of that when those DIPs are discussed. Ultimately though, no matter who comes up with the DIP, Walter has to be convinced that it's a good idea. It's just that if it's his DIP, he's already convinced that it's a good idea, so someone has to then convince him otherwise for it to not be accepted. It's hard to argue against an idea that isn't fully formed. All of his arguments against the DIP were based on the fact that nothing is implemented. It's easy to say, Oh that'll be fixed in Part 2 of a third DIP down the road. D wouldn't be what it is today. You can look at it both ways, in that sense. (Half full glass) Should create a DIPW process then, duck the foundation and any formalities. Which stands for DIPWalter, which simply consists of a single step where a single topic tries to convince Walter it's a bad idea. Why have two community reviews? Those are made with the assumption that the DIP will actually change between the reviews. What's the point of a "formal review" when there's just Walter talking to himself (rip Andrei). Why waste everyone's time on formalities when they obviously are irrelevant?
Re: LDC 1.18.0
On Thursday, 17 October 2019 at 04:04:41 UTC, Newbie2019 wrote: On Wednesday, 16 October 2019 at 22:31:41 UTC, kinke wrote: Thanks for keep up the good work. Android CI is really a great for mobile users, I wish some day there also include IOS cross build binary package. Yes, I wish it too. LDC for iOS needed.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Monday, October 21, 2019 6:59:21 AM MDT Exil via Digitalmars-d-announce wrote: > > This proposal is one step toward a larger goal outlined in the > > > > blog post ['Ownership and Borrowing in > > D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/). > > That's the only line that was added, no other changes were made > to the core DIP from the first revision to the last. Big ducking > surprise this got accepted anyways. Did you expect anything else? Given that it was Walter's DIP, and he's making the decisions, the only way that the DIP was going to change was if he were convinced that the DIP was flawed. He's been convinced of that before (e.g. the DIP that was for adding a bottom type was written by Walter, but it was rejected, because the community convinced him that it was a bad idea). He just wasn't convinced that this DIP was a bad idea. Personally, I didn't see any problem with this DIP, since it just tightened down @safe a bit. Whether the next steps in the "larger goal" are good ones is another matter entirely, and those will be put in a DIP (or multiple DIPs) and argued on their own at some point. And if they're bad ideas, then hopefully he will be convinced of that when those DIPs are discussed. Ultimately though, no matter who comes up with the DIP, Walter has to be convinced that it's a good idea. It's just that if it's his DIP, he's already convinced that it's a good idea, so someone has to then convince him otherwise for it to not be accepted. Fortunately, while Walter certainly doesn't have a perfect track record, he has a pretty darn good one, or D wouldn't be what it is today. - Jonathan M Davis
