Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote: "“But D has a GC!”, I hear you exclaim. No body said that. Funny how you chose the simplest argument to argue against. Yes, but it’s also a systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default." https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/ -Alex Despite the mess DIP1000 was and still is, it did actually solve some problems. Even still there are bugs related to DIP1000 that aren't being fixed anymore cause the focus has already shifted away from it. The DIP1000 still says it will be "updated" but that's most likely never going to happen. Especially considering this DIP1021 has an example of a bug that the DIP doesn't even fix. For @safe, it is already safe if you use the GC. If you use @safe with DIP1021 you are restricting the user in what code they can write and it doesn't make their code any safer. This is just a flat restriction for no purpose for them. For manual memory management, this does not solve the problem illustrated by the DIP's example. Especially considering that in a blog post (formally unbeknownst to the DIP1021) the intention is to introduce a @live attribute. And the actual problem won't actually be fixed unless the @live attribute is there. So it doesn't benefit @safe users, it doesn't benefit manual memory management users and it won't come to fruition until some future attribute is implemented. I'm all for implementing Rust's memory management in D, but this is just horrible project management in all regards. Maybe it wouldn't be that big of a deal if it was a smaller project where you can muddle through finding your way willy nilly, but the whole purpose of the formalities -is- should be so you don't do that.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:53:55 UTC, Mike Parker wrote: 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 Why even have a final review then? Shouldn't the community review only end if there are no more changes to be made? If changes are made after the Final Review, then those changes won't get to be reviewed. If the author doesn't take any criticism of their work and decides their DIP is a shiny pile of words that doesn't needy any more polishing, why have the community review the same thing again? If that is how it is intended to be then it is a flawed system at that.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:49:52 UTC, Mike Parker wrote: 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. I'd love to see the transcript of that. What was included in the DIP was rather short (a single sentence) compared to other DIPs.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 15:10:23 UTC, 12345swordy wrote: On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Not to mention the problem is actually solved just by using the GC. The d language is marked as a system programming language. The GC is not going to cut it to a lot of people.(Did you forget the whole betterC flag?) -Alex A flag that was only added recently (relative to the lifespan of D)? D isn't a systems programming language, there's entire threads dedicated to the topic. You can call it whatever you want, but if that's what it wasn't to identify as, it's bottom of the barrel in terms of system programming languages.
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: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
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.
Re: D GUI Framework (responsive grid teaser)
Is the source available anywhere? Would be interesting to look through unless this is close source?
Re: bool (was DConf 2019 AGM Livestream)
On Sunday, 12 May 2019 at 10:58:49 UTC, Andrei Alexandrescu wrote: Bringing it up over and over again, like a perennial fight in a marriage, with the hope of finally convincing the spouse on the wrongness of their views - that all is wasted time. There's a bunch of big rocks to move. I take it from this response you mean, once a DIP is rejected it would never be looked at again, even if a second DIP was created for the same purpose with different arguments? So changes like this one should be reversed then? https://github.com/dlang/phobos/pull/5343 And isIntegral should also be updated to include bool? Where is the line drawn? Should it be treated like an integral only in the language but not in phobos?
Re: DConf 2019 AGM Livestream
On Saturday, 11 May 2019 at 07:53:36 UTC, Mike Parker wrote:
Anyone interested in the AGM can watch it at the following
link. You can leave feedback there, in IRC, or in Discord.
https://youtu.be/cpTAtiboIDs
Regarding the discussion of how bool is handled...
It's a one bit integer so it should behave like a one bit
integer
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s
Wouldn't entirely say that, someone already pointed out the ++
operator but it does not behave like an integer in other respects
either.
It does not overflow the same way an integer does, max + 1 -> 0.
A 1-bit integer can only hold two values, 0/1. 1 + 1 should equal
0, but instead it equals 1. It is already a special case.
Converting any integer will result in the bool being set to 1,
the only time it isn't is when the integer is zero. Not like a
1-bit integer would.
writeln( cast(ubyte) (ubyte.max + 1) ); // 0
writeln( cast(ushort)(ushort.max + 1) ); // 0
writeln( cast(uint) (uint.max + 1) ); // 0
writeln( cast(ulong) (ulong.max + 1) ); // 0
writeln( cast(bool) (bool.max + 1) ); // 1 (true)
Maybe you got too many overloads and what are you trying to do
with those overloads that it would matter that it called a
different overload
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h20m42s
I've seen it a few times, if you just a simple variant or some
sort of generic script type to be used. You don't need "too many
overloads" it literally takes 2, the minimum number of overloads
for there to be an overload.
struct SomeVariantOrScriptTypeGeneric {
enum Type { Bool, Long, }
Type type;
union { bool bool_; long long_; }
this( bool ) { type = Type.Bool; }
this( long ) { type = Type.Long; }
}
enum int a = 1;
enum int b = 2;
SomeVariantOrScriptTypeGeneric v = b - a; // type == Bool
Sure it is convenient to have some properties of bool also be
similar to an integer, but it can definitely not be swapped in to
be used like a 1-bit integer and there are already plenty of
special rules for it.
