Re: On the future of DIP1000
On Sunday, 28 August 2016 at 07:43:47 UTC, Walter Bright wrote: You've had a couple of worthwhile posts, you're welcome to stay and continue in that vein. Posts with unprofessional behavior, politics, etc., will be simply deleted. D deserved someone better than a person like Andrei, but it doesn't matter anymore. Goodbye Mr. Bright, and good luck to D.
Re: On the future of DIP1000
On 8/28/2016 3:39 AM, Dicebot wrote: There have never been a single professional or at least constructively fashioned post from that account and tolerating that harms D public image. I have learned not to argue about this but I am very unhappy that you not only allow but encourage both off-topic and flamebait derailing of _announcement_ threads. Off-topic always happens anyway, but it's fair I should have suggested starting a new thread. But I thought the discussion of macros was reasonable. Criticism of D is ok. His abusive posts were deleted, though it's not possible to delete things from the mail interface, and sometimes it takes a while for the dforum software to sync. It isn't really practical to ban individuals, because an account is not necessary to post. We can only delete posts. I also like to believe people are redeemable and will give anyone a second chance if they'll comport themselves appropriately. I also try to err on the side of being permissive, though nearly all of his posts were so far over the line there was no head scratching to be done.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 20:54:02 UTC, Walter Bright wrote: On 8/27/2016 9:04 AM, Dicebot wrote: Please never reply to that person unless you are his other account. Not in an announce threads at least. If the post is reasonably professional, it's ok to. Abusive posts just get deleted. There have never been a single professional or at least constructively fashioned post from that account and tolerating that harms D public image. I have learned not to argue about this but I am very unhappy that you not only allow but encourage both off-topic and flamebait derailing of _announcement_ threads.
Re: On the future of DIP1000
On 8/27/2016 11:58 PM, Bill Hicks wrote: white men There are plenty of other forums for politics. Not this one. You've had a couple of worthwhile posts, you're welcome to stay and continue in that vein. Posts with unprofessional behavior, politics, etc., will be simply deleted.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 20:47:16 UTC, Walter Bright wrote: On 8/27/2016 8:19 AM, Bill Hicks wrote: I believe Andrei's point was that Rust had focused on one problem to the relative exclusion of others, not that memory safety was unimportant. Rust, to its credit, has changed the perception of the importance of memory safety. I think it's disingenuous to say that Rust has focused only on one problem. As it is, Rust is a much more capable system programming language than D. Besides, Andrei is not a C++ expert (I know most think this is the case because he's famous, but he isn't), and he's certainly not a PL expert. Not even close. So I don't think he has the right to criticize other programming languages, specially in such a condescending manner. The problem with misuse of features like macros is lack of proper training and education, not so much the features themselves. This argument is often put forward as the solution, but it just does not scale. This is why so, so much code has security bugs in it. Heck, the whole reason people move from C to Rust is because education and training have proved inadequate to get safe code written in C, despite decades of trying. Sure, some language features cause more problems than not, regardless of how much training one receives, but I don't think hygienic macros is one of them. BTW, most of that "code with security bugs in it" has been written by white men. Had it been written by non-whites, and god forbid women, then the programmers would have been blamed for the defects. But because it's been written by white men, they are choosing to blame the tools and the languages, and not the programmers.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote: On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote: On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote: We've never mocked Rust's safety features, although I have posted that they are too complex for D and desire a simpler system. "A disharmonic personality. Reading any amount of Rust code evokes the joke 'friends don't let friends skip leg day' and the comic imagery (https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLsA&biw=1582&bih=1352) of men with hulky torsos resting on skinny legs". --Andrei If that's not mockery, then how would you describe it? On my phone so can only speak from memory, but if it serves then he went on to equally criticise D for its warts and blemishes. It would be cherry-picking to ignore context and just say that he threw mockery at rust. Riiight! Nothing has been taken out of context, so don't get it twisted. In his post Andrei did cover the disadvantages of D, but his tone was very different when talking about Rust and Go. And yes, he was mocking Rust and even teasing Go for that matter. Andrei's Quora post was mostly a PR stunt: when your competition has a larger number of subscribers/users, you attack it in order to steal the spotlight. I haven't seen this kind of behavior from Rust or Go creators towards D.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 16:04:34 UTC, Dicebot wrote: On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote: ... Please never reply to that person unless you are his other account. Not in an announce threads at least. I ran a quick linguistic analysis and it shows that there is 93% probability that that was Andrei posting anonymously.
Re: On the future of DIP1000
On 8/27/2016 9:04 AM, Dicebot wrote: Please never reply to that person unless you are his other account. Not in an announce threads at least. If the post is reasonably professional, it's ok to. Abusive posts just get deleted.
Re: On the future of DIP1000
Best to add him to your killfile instead of responding.
Re: On the future of DIP1000
On 8/27/2016 8:19 AM, Bill Hicks wrote: I believe Andrei's point was that Rust had focused on one problem to the relative exclusion of others, not that memory safety was unimportant. Rust, to its credit, has changed the perception of the importance of memory safety. I bet in a few years we'll see hygienic macro system in D. I seriously doubt it (they've been proposed many times). I haven't studied Rust's macro system, but others I've seen (expression templates, user defined syntax, CPP, macro assemblers, etc.) are very powerful, but ultimately off-putting because it makes code very hard to understand. I'm not a big fan of macros either, but should we ban chainsaws too because they have the potential to cause serious injuries? Every language bans certain things because they are too powerful and too error-prone. For example, monkey-patching in Ruby - it is undeniably powerful, but people are moving away from Ruby because it just isn't worth it. The problem with misuse of features like macros is lack of proper training and education, not so much the features themselves. This argument is often put forward as the solution, but it just does not scale. This is why so, so much code has security bugs in it. Heck, the whole reason people move from C to Rust is because education and training have proved inadequate to get safe code written in C, despite decades of trying. Large percentage of professional developers don't even have a degree in CS/SE, and they lack proper training. Most of them become developers because of the money, and many of them get hired for the wrong reasons (just look at the interview process), and these are the kinds of developers responsible for large percentage of the garbage code that's out there. Corporations that hire them care mostly about producing the largest amount of code in the shortest amount of time to increase earnings and profits. Many helper tools and dumbed-down languages have already been created particularly for these kinds of crowds. Abuse of macros is hardly confined to poorly trained developers. I've seen paper after paper with complex macro abuse presented at conferences by top professionals, even PhDs. (I'm also sure that in their opinion these are legitimate uses of macros. My opinion on macros is hardly universal.) Unfortunately, we see a similar pattern in other areas. The dumbing down of society and the deteriorating education system is not an accident. Just compare the writing skills of the average person from, say, the 1930s to what we have today, not to mention their level of intellect. And today we have spell checkers and software to check grammar, how amusing. Should we make changes to the English language to help these people make fewer mistakes? There are a lot of specialized variants of English that attempt to remove mistakes, ambiguities, and nail down meanings. BTW, I don't agree there ever was a golden age of education in America.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote: ... Please never reply to that person unless you are his other account. Not in an announce threads at least.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote: On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote: We've never mocked Rust's safety features, although I have posted that they are too complex for D and desire a simpler system. "A disharmonic personality. Reading any amount of Rust code evokes the joke 'friends don't let friends skip leg day' and the comic imagery (https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLsA&biw=1582&bih=1352) of men with hulky torsos resting on skinny legs". --Andrei If that's not mockery, then how would you describe it? On my phone so can only speak from memory, but if it serves then he went on to equally criticise D for its warts and blemishes. It would be cherry-picking to ignore context and just say that he threw mockery at rust.
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote: We've never mocked Rust's safety features, although I have posted that they are too complex for D and desire a simpler system. "A disharmonic personality. Reading any amount of Rust code evokes the joke 'friends don't let friends skip leg day' and the comic imagery (https://www.google.com/search?q=friends+don%27t+let+friends+skip+leg+day&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0CB0QsARqFQoTCM_ViveKhMkCFUfZPgodVsgLsA&biw=1582&bih=1352) of men with hulky torsos resting on skinny legs". --Andrei If that's not mockery, then how would you describe it? but now they're trying to be more like it. We've had proposals for more safety annotation in D for at least 10 years (from Bartosz Milewski), but they've always been more complex than I wanted. DIP1000 is a much simpler scheme. And he continues: "Unfortunately, that's seldom the problem domain, which means a large fraction of the thinking and coding are dedicated to essentially a clerical job (which GC languages actually automate out of sight). Safe, deterministic memory reclamation is a hard problem, but is not the only problem or even the most important problem in a program". --Andrei It should be quiet obvious that a non-optional GC does not belong in a language that claims to be a system programming language. Not only that, but for all these years D has had a rather poor GC. At last we've witnessed the removal of GC usage from Phobos, and, if my understanding is correct, y'all trying to change the role GC plays in the language. So maybe the Rust folks know something Dr. Andrei doesn't? And why criticize Rust just because they've taken a potentially better approach to memory management while 'D has had the downsides of GC but hasn't enjoyed its benefits'? Besides, if you can't please the Linux-kernel-developer type, then you ain't got a system programming language. And if we are honest, I don't think D fits anywhere. I bet in a few years we'll see hygienic macro system in D. I seriously doubt it (they've been proposed many times). I haven't studied Rust's macro system, but others I've seen (expression templates, user defined syntax, CPP, macro assemblers, etc.) are very powerful, but ultimately off-putting because it makes code very hard to understand. ... A macro system is like putting a 2000 HP motor in a car. It's sure exciting, but ultimately you just don't want it in a daily driver, or anyplace other than the track, because it'll kill you. I'm not a big fan of macros either, but should we ban chainsaws too because they have the potential to cause serious injuries? The problem with misuse of features like macros is lack of proper training and education, not so much the features themselves. Large percentage of professional developers don't even have a degree in CS/SE, and they lack proper training. Most of them become developers because of the money, and many of them get hired for the wrong reasons (just look at the interview process), and these are the kinds of developers responsible for large percentage of the garbage code that's out there. Corporations that hire them care mostly about producing the largest amount of code in the shortest amount of time to increase earnings and profits. Many helper tools and dumbed-down languages have already been created particularly for these kinds of crowds. Unfortunately, we see a similar pattern in other areas. The dumbing down of society and the deteriorating education system is not an accident. Just compare the writing skills of the average person from, say, the 1930s to what we have today, not to mention their level of intellect. And today we have spell checkers and software to check grammar, how amusing. Should we make changes to the English language to help these people make fewer mistakes?
Re: On the future of DIP1000
On Saturday, 27 August 2016 at 06:37:58 UTC, Andrej Mitrovic wrote: On 8/21/16, Dicebot via Digitalmars-d-announce wrote: This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) Trivia question: why is it named DIP 1000? We've had less than 100 DIPs before https://github.com/dlang/DIPs was opened, the jump seems very arbitrary to me (and it makes it appear as if we had a thousand DIPs already to the outsiders) To clearly disambugate all new DIPs from all old ones by the number only.
Re: On the future of DIP1000
On 8/21/16, Dicebot via Digitalmars-d-announce wrote: > This week I had a tele-meeting with Andrei and Walter regarding > the fate > of DIP1000 > (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) Trivia question: why is it named DIP 1000? We've had less than 100 DIPs before https://github.com/dlang/DIPs was opened, the jump seems very arbitrary to me (and it makes it appear as if we had a thousand DIPs already to the outsiders)
Re: On the future of DIP1000
On 8/26/2016 9:53 PM, Bill Hicks wrote: On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote: we want memory safe code w/o the GC. -Martin Rust has had that since day one. Funny how not too long ago D core was mocking Rust, We've never mocked Rust's safety features, although I have posted that they are too complex for D and desire a simpler system. but now they're trying to be more like it. We've had proposals for more safety annotation in D for at least 10 years (from Bartosz Milewski), but they've always been more complex than I wanted. DIP1000 is a much simpler scheme. I bet in a few years we'll see hygienic macro system in D. I seriously doubt it (they've been proposed many times). I haven't studied Rust's macro system, but others I've seen (expression templates, user defined syntax, CPP, macro assemblers, etc.) are very powerful, but ultimately off-putting because it makes code very hard to understand. For example, Microsoft put a very powerful macro system in their assembler, MASM. Programmers went to town with it, each programmer essentially inventing their own language that was undocumented and unreadable to anyone else. A Microsoft programmer related to me that once he was given the job of updating a large assembler program that someone no longer there had written in their own invented macro language. He got it updated and fixed in short order. Surprised, his manager asked him how he figured out how it worked, as everyone else who tried had failed. My friend said he didn't even attempt to figure it out. He assembled it, and ran the result through a disassembler (our very own OBJ2ASM) which made it nice, readable, and fixable. An earlier incarnation of myself had also succumbed to the siren song of inventing my own assembler language via macros. Over time, I gradually stopped using it and reverted to writing vanilla, understandable assembler. I've seen the story repeated with CPP macros and expression templates, and I've heard similar accounts about other macro systems. Making macros hygienic doesn't fix it. P.S. I still from time to time use OBJ2ASM to figure out what someone's wretched ASM file is doing, like I'll run CPP by itself to see what some miserable CPP abuse is actually generating. I've also been gradually removing all CPP use from my own C++ code (the dmd back end). A macro system is like putting a 2000 HP motor in a car. It's sure exciting, but ultimately you just don't want it in a daily driver, or anyplace other than the track, because it'll kill you.
Re: On the future of DIP1000
On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote: we want memory safe code w/o the GC. -Martin Rust has had that since day one. Funny how not too long ago D core was mocking Rust, but now they're trying to be more like it. I bet in a few years we'll see hygienic macro system in D.
Re: On the future of DIP1000
On Tuesday, 23 August 2016 at 18:37:46 UTC, Dicebot wrote: By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place. Well the fact that we have a public review and can criticize the proposal is as much as you can get from a peer reviewed process. If you have valid and important arguments they won't just get ignored. In fact [DIP74](http://wiki.dlang.org/DIP74) faced a lot of criticism for not properly addressing escape checking first, that's one of the main reasons why we have DIP1000 now. The overall goal is also clear and has been stated ([Vision/2016H2 - D Wiki](https://wiki.dlang.org/Vision/2016H2#H2_2016_Priorities)), we want memory safe code w/o the GC. -Martin
Re: On the future of DIP1000
On 08/22/2016 09:44 AM, Jacob Carlborg wrote: > It would be nice to have the whole picture now, before implementing > DIP1000. Then it's possible to review them together, making sure the end > goal is actual possible to achieve. Now we just have to trust Andrei and > Walter that all features will come together making the end goal > possible. We've already seen in the past that some features don't play > well together. My understanding is that those are not supposed to be related in any direct way and danger of @trusted destructor is inherent to DIP1000 design (it should be better clarified in document itself though, see https://github.com/dlang/DIPs/pull/35) > I'm also not a big fan that the DIP is approved right from the start. > Then it's not a DIP, it's more of a FYI. It makes the whole process kind > of pointless since Andrei and Walter can choose to ignore the feedback. By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place. I would personally prefer to see more of a commitee approach for validating such changes but that concept is far beyond available resources and community engagement. If both language authors agree that certain issue is urgent to solve than, in absence of formally written counter-proposals, there is no other way but to move ahead. Again, the DIP process is not for Walter or Andrei - it is for everyone else wanting to get their attention and submit good quality technical proposal. I hope authors of already submitted DIPs will improve them to required content bar and we will see how the process actually work but that is still to come. Note that during the meeting I did go through the list of all comments submitted through the community feedback to ensure that nothing was simply missed or forgotten and every issue is acknowledged. But all the decision making is 100% for Andrei/Walter in the end and I don't see how it can be different with existing state of affairs. signature.asc Description: OpenPGP digital signature
Re: On the future of DIP1000
On 08/22/2016 12:46 AM, John Colvin wrote: > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: >> - scope is @safe only > > Why? I might have @system code that could still benefit from scope. Because it can't provide expected guarantees within feature set allowed by @system - it is too permissive for such simple system. Probably actual scope semantics will remain in @system but it won't guarantee anything. signature.asc Description: OpenPGP digital signature
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. It can be reviewed after the spec is inferred from implementation. But yes, it can be unclear how the implementation can affect the review process. Do you have an alternative design for scope?
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together. It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture. I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback. What he said !
Re: On the future of DIP1000
On 2016-08-21 22:01, Dicebot wrote: This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) and intented way to move forward with it. This is a short summary of the meeting. Approval of DIP1000 --- DIP1000 is going to be approved as the basis of the idea but exact specification may change during implementation and as a result of incorporating some ideas from feedback threads (http://forum.dlang.org/thread/pqsiqmkxenrwxoruz...@forum.dlang.org and http://forum.dlang.org/thread/rwxcfapvpfiqmfsui...@forum.dlang.org). Core principles that are sure to stay at this point: - scope is a storage class - scope is non-transitive - scope is @safe only - responsibility of implementing complicated scope-using types is on developer, compiler magic is intended to be minimal Any changes in intended DIP1000 spec will be reflected in original document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). Implementation of DIP1000 - Walter is currently working on implementing the support via https://github.com/dlang/dmd/pull/5972, which will take some time. Once it is more feature complete I'll contact Martin for possible out-of-release preview compiler builds from that branch to try it out easily. About that time we will start another feedback thread in the NG with a more practical focus - featuring more code examples and design idioms. Life after DIP1000 -- It is acknowledged that DIP1000 itself does not allow to implemented completely @safe reference counting, primarily because of an issue with @trusted destructor and re-assignment. Intention is to follow up with another proposal (not directly related) to address the issue from another angle - but this will only become in focus after DIP1000 is finished. It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together. It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture. I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback. -- /Jacob Carlborg
Re: On the future of DIP1000
On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote: Well, if you typically try and restrict your @system code to small parts of your program and use @trusted to turn them into @safe, then the vast majority of your program will be @safe. As I understand it, that's at least how it was _intended_ that @system be dealt with - though plenty of folks just don't bother with @safe, and it's certainly the case that code out there doesn't restrict the @system portions as much as it could. So, at least _in theory_, if you're using @safe as intended, even if you have a fair number of code snippets which are @system, you can take advantage of stuff like scope in most of your code. I don't know how well that will work in practice though. I can think of two big reasons to restrict something like this to @safe code though. One is that implementing something like this usually means declaring some stuff illegal that is actually safe, because the compiler can't be perfect about it (a similar example would be how a lot of lambdas end up allocating closures in order to be @safe when they don't actually need to; the compiler simply isn't smart enough to figure out that it isn't necessary and may or may not be able to with what the language allows the programmer to do). Another reason is that sometimes in order to make certain guarantees, the compiler has to be able to assume things that aren't necessarily true in @system code, even if they happen to be true for most @system code. I agree. If there's a lot of @system code in a program, something has gone awry in its design. I understand the desire to be able to turn each individual safety feature on and off, but don't think the code really will be better off that way.
Re: On the future of DIP1000
On Sunday, August 21, 2016 21:52:59 John Colvin via Digitalmars-d-announce wrote: > On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote: > > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: > >> - scope is @safe only > > > > Why? I might have @system code that could still benefit from > > scope. > > I guess it would be too restrictive, but I'm just a bit > frustrated at having to choose between lots of compiler checking > and none at all. I wish there was a flag for the compiler that > would give @safe violations as warnings in @system / @trusted > code, it would be too noisy for routine use but it would be great > to occasionally look through. Well, if you typically try and restrict your @system code to small parts of your program and use @trusted to turn them into @safe, then the vast majority of your program will be @safe. As I understand it, that's at least how it was _intended_ that @system be dealt with - though plenty of folks just don't bother with @safe, and it's certainly the case that code out there doesn't restrict the @system portions as much as it could. So, at least _in theory_, if you're using @safe as intended, even if you have a fair number of code snippets which are @system, you can take advantage of stuff like scope in most of your code. I don't know how well that will work in practice though. I can think of two big reasons to restrict something like this to @safe code though. One is that implementing something like this usually means declaring some stuff illegal that is actually safe, because the compiler can't be perfect about it (a similar example would be how a lot of lambdas end up allocating closures in order to be @safe when they don't actually need to; the compiler simply isn't smart enough to figure out that it isn't necessary and may or may not be able to with what the language allows the programmer to do). Another reason is that sometimes in order to make certain guarantees, the compiler has to be able to assume things that aren't necessarily true in @system code, even if they happen to be true for most @system code. - Jonathan M Davis
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote: On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope. I guess it would be too restrictive, but I'm just a bit frustrated at having to choose between lots of compiler checking and none at all. I wish there was a flag for the compiler that would give @safe violations as warnings in @system / @trusted code, it would be too noisy for routine use but it would be great to occasionally look through.
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope.
On the future of DIP1000
This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) and intented way to move forward with it. This is a short summary of the meeting. Approval of DIP1000 --- DIP1000 is going to be approved as the basis of the idea but exact specification may change during implementation and as a result of incorporating some ideas from feedback threads (http://forum.dlang.org/thread/pqsiqmkxenrwxoruz...@forum.dlang.org and http://forum.dlang.org/thread/rwxcfapvpfiqmfsui...@forum.dlang.org). Core principles that are sure to stay at this point: - scope is a storage class - scope is non-transitive - scope is @safe only - responsibility of implementing complicated scope-using types is on developer, compiler magic is intended to be minimal Any changes in intended DIP1000 spec will be reflected in original document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). Implementation of DIP1000 - Walter is currently working on implementing the support via https://github.com/dlang/dmd/pull/5972, which will take some time. Once it is more feature complete I'll contact Martin for possible out-of-release preview compiler builds from that branch to try it out easily. About that time we will start another feedback thread in the NG with a more practical focus - featuring more code examples and design idioms. Life after DIP1000 -- It is acknowledged that DIP1000 itself does not allow to implemented completely @safe reference counting, primarily because of an issue with @trusted destructor and re-assignment. Intention is to follow up with another proposal (not directly related) to address the issue from another angle - but this will only become in focus after DIP1000 is finished.
