Re: D is dead
On 23/08/18 09:17, Jacob Carlborg wrote: On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote: One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call). I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred. -- /Jacob Carlborg Here's the interesting question, though: is this *going* to happen? We've known about this problem for ages now. No movement. Some of the other problems are considerably less easy to fix. Examples: A struct may be @disabled this(this), @disable this() and/or @disable init. Can you say that libraries.. Actually, strike that. Can you say that the *standard* libraries work with all 8 combinations? Shachar
Re: D is dead
On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote: Let's start with this one: https://issues.dlang.org/show_bug.cgi?id=14246#c6 The problems I'm talking about are not easily fixable. They stem from features not playing well together. One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call). The only real problem with D is that it's a language designed with GC in mind, yet there are numerous attempts to use it without GC. Also, supporting GC-less programming gets in the way of improving D's GC (which is pretty damn bad by modern standards). That's the only real technical problem. For example, the "bug" above just means that D doesn't support RAII (in the C++ sense). That's hardly a *fatal flaw*. Lots of languages don't support RAII. Python, Java, C# - tons of code were written in those. And yes, most of those just use GC to dispose of memory - other resources are rarely used (compared to memory) and it's not a problem to manage them manually. You also mentioned lazy parameters allocating... GC thing again. Just allocate then? No? IMO, if getting the maximum number of users is the main goal, D is indeed going the wrong way. It would be better to get rid of @nogc, betterC, dip1000, implement write barriers and use them to improve GC. Martin Nowak (I think) mentioned that write barriers will decrease performance of D programs by 1-5%. Seems like a small price to pay for better GC with shorter pauses. It would also probably be simpler technically than stuff like dip1000 and rewriting Phobos. Of course, maximizing the number of users is not the only goal, or even the main one. My understanding is that Walter wants a "systems language" with "zero cost abstractions". Well, it's very well possible that D's design precludes that. Other than memory management, I don't see any real fundamental problems.
Re: D is dead
On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote: One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call). I don't see why we just can't add support for scoped lazy parameters. It's already in the language just with a different syntax (delegates). That would probably be an easy fix (last famous words :)). I guess it would be better if it could be inferred. -- /Jacob Carlborg
Re: D is dead
On 23/08/18 09:04, Mike Franklin wrote: On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. The D Foundation has an Open Collective page (https://opencollective.com/dlang) with a $12,000 annual "Corporate Bronze" option that includes 3 priority bug fixes per month. Is that not a worthwhile investment for Weka or other organizations invested in D to help address some of the problems you're encountering? If not, is there an option that would be? I will definitely pass it on. Shachar
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. The D Foundation has an Open Collective page (https://opencollective.com/dlang) with a $12,000 annual "Corporate Bronze" option that includes 3 priority bug fixes per month. Is that not a worthwhile investment for Weka or other organizations invested in D to help address some of the problems you're encountering? If not, is there an option that would be? Mike
Re: D is dead
On 23/08/18 08:20, Nicholas Wilson wrote: On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: No, no and no. I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change. It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view. Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. A list, please? Now that I actually have time to fix things, I intend to do so. Let's start with this one: https://issues.dlang.org/show_bug.cgi?id=14246#c6 The problems I'm talking about are not easily fixable. They stem from features not playing well together. One that hurt me lately was a way to pass a scoped lazy argument (i.e. - to specify that the implicit delegate need not allocate its frame, because it is not used outside the function call). Shachar
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: No, no and no. I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change. It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view. Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. A list, please? Now that I actually have time to fix things, I intend to do so. And by "fatal", I mean literally flaws that are likely to literally kill the language. And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis. And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they? This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting. And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. That reminds me, what happened to our conversation with Ali Çehreli about splitting general into Technical and less technical? Not to imply that the problems listed are purely technical. There is a distinct lack of well documented direction beyond incremental improvements. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. With great regrets, Shachar Indeed. It is time to push, then. Nic
Re: D is dead
On Thursday, 23 August 2018 at 04:59:47 UTC, Dukc wrote: On Thursday, 23 August 2018 at 04:44:47 UTC, Shachar Shemesh wrote: But, again, it is interesting to see what you took from my mail. I think the biggest problem is lack of reviewers when making PR:s. The fact that we have D language foundation, state of D survey, extensive autotester and regular release schelude seem to imply, for me, that much more than ADD is being done. But then again, my D projects so far are too small that I could really know where the problems are. It may be that in time, if they grow, I start to agree with you. JinShil referenced in another thread a PR where Walter and Andrei just ignored the review and merged the pull request (I had to laugh). A valid merge-stopper (missing/wrong documentation) was called "bureaucracy". https://github.com/dlang/dmd/pull/8346
Re: D is dead
On Thursday, 23 August 2018 at 04:44:47 UTC, Shachar Shemesh wrote: But, again, it is interesting to see what you took from my mail. I think the biggest problem is lack of reviewers when making PR:s. The fact that we have D language foundation, state of D survey, extensive autotester and regular release schelude seem to imply, for me, that much more than ADD is being done. But then again, my D projects so far are too small that I could really know where the problems are. It may be that in time, if they grow, I start to agree with you.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: No, no and no. I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change. It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view. Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis. And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they? This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting. And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. With great regrets, Shachar "anarchy driven development" is a pearl. It is also mood driven development. Yesterday was scope and -dip1000 super important, today is betterC very hot and everyone works on betterC druntime, betterC Phobos, betterC libraries. Maybe -dip1000 will be made default at some point and the language will get another one well-intentioned but only half-working feature. And I'm beginning to doubt that the real problem is that the community doesn't help. Don't get me wrong, I do development in absolutely the same, anarchy driven :), way. Sometimes I can't work long enough at the same thing, sometimes I lose interest. It is also great for research and trying out new ideas since D tries to be innovative and offer a better developer experience. And I can also understand that the language authors want to control the evolution of the language and try make it better testing new ideas. But this kind of development doesn't work anymore that well for commercial customers that aren't (only) interested in research. From this perspective D becomes over-complicated, half-finished language. And nobody can tell what will be "in" tomorrow.
Re: D is dead
On 23/08/18 07:35, Dukc wrote: On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. How so? If he's right with those issues, they can definitely prevent D from becoming mainstream, but how would they kill D? I mean, will not there always be some existing users who have no need or wish to move on? Maintaining a language requires a lot of work. The "payback" for that work comes from people who actually use that work. If the D community starts to contract, it will become more and more difficult to find people willing to work on D's core features, which will lead to stagnation which is the same as death. But, again, it is interesting to see what you took from my mail. I'd be much more worried about the fact that it is working with D that caused people to recognize the problems as fundamental than about what "death" means in this context. Shachar
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. How so? If he's right with those issues, they can definitely prevent D from becoming mainstream, but how would they kill D? I mean, will not there always be some existing users who have no need or wish to move on?
D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On 22/08/18 21:34, Ali wrote: On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote: Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. Yea, I agree, the negatives are not really negative Walter not matter how smart he is, he is one man who can work on the so many things at the same time Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors No, no and no. I was holding out on replying to this thread to see how the community would react. The vibe I'm getting, however, is that the people who are seeing D's problems have given up on affecting change. It is no secret that when I joined Weka, I was a sole D detractor among a company quite enamored with the language. I used to have quite heated water cooler debates about that point of view. Every single one of the people rushing to defend D at the time has since come around. There is still some debate on whether, points vs. counter points, choosing D was a good idea, but the overwhelming consensus inside Weka today is that D has *fatal* flaws and no path to fixing them. And by "fatal", I mean literally flaws that are likely to literally kill the language. And the thing that brought them around is not my power of persuasion. The thing that brought them around was spending a couple of years working with the language on an every-day basis. And you will notice this in the way Weka employees talk on this forum: except me, they all disappeared. You used to see Idan, Tomer and Eyal post here. Where are they? This forum is hostile to criticism, and generally tries to keep everyone using D the same way. If you're cutting edge D, the forum is almost no help at all. Consensus among former posters here is that it is generally a waste of time, so almost everyone left, and those who didn't, stopped posting. And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. With great regrets, Shachar
Re: [OT] "I like writing in D" - Hans Zimmer
On Wednesday, 22 August 2018 at 22:51:58 UTC, Piotrek wrote: You may already know that from youtube. It seems D starts getting traction even among musicians: https://www.youtube.com/watch?v=yCX1Ze3OcKo&feature=youtu.be&t=64 That really put a smile on my face :D And it would be a nice example of a D advertising campaign ;) Cheers, Piotrek LOL I didn't get it at first! I was looking at the computers expecting some code!
Re: [OT] Leverage Points
On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu wrote: where are the best leverage points in making the D language more successful. I'm still internalizing the article and thinking about how it applies to the "D system", but I've always thought facilitating the incorporation of GDC into GCC to be the single most accelerating thing we could do to gain more adoption. It somewhat fits into *7. The gain around driving positive feedback loops*. But there's risk associated with that. Walter has often said that "build it and they will come" is a Hollywood myth, but I disagree. Part of the reason why D hasn't achieved mass adoption, isn't because it's not marketed well, but because it has a number of flaws. Most of us see the *potential* of D, and are able to look past the flaws, with the faith (hopefully not misplaced) that they will one day be addressed. Others only see the flaws and the appeal of other programming languages with more resources, better management, more talent, and especially more velocity toward their goals. I often worry that if we encourage adoption, before we have something worthy of adoption, we'll only leave users with a bad taste in their mouth [0]. I've already seen a number of people, some major contributors, leave D for greener pastures. Most of the contributors that built the D runtime and did the majority of bug fixing in the compiler are gone now. At this point in time, I can only recommend D professionally to teams that are risk takers, have the aptitude to solve their own problems, and have the resources and willingness to be D contributors. We should probably be looking more for leverage points to help us better capitalize on the resources and talent we have and bring in more. Unfortunately I'm seeing an over-correction in *8. The strength of negative feedback loops, relative to the impacts they are trying to correct against*. As we try to get contributors to focus on the things that matter (at least to the powers that be), we frustrate them until they close their pull requests or just give up [1] [2]. It took me a few years to find my "in", and I'm still not really "in", but I learned that the *little things* that some consider a distraction are how people get started contributing to D. I've often said that we actually don't need more contributors; but more reviewers. There's a catch to that, though; they're not going to become reviewers if they can't first become contributors. So perhaps, I need to correct my perspective. So, I'll close with this: We should probably be more welcoming to those willing to contribute, let them work on the little stuff that's important to them, throw them a bone or two, review their pull requests in a timely manner, etc... I think those contributors will eventually become our reviewers, and then they will eventually lessen the burden so veterans can focus on the things that they think are higher priorities. This is a positive feedback loop. Help people become positive contributors, and those contributors will eventually help the next generation. I think there are a few little things the leadership, especially, can do to prime that pump, starting with being more active, helpful, and gracious with things that are currently sitting in the PR queue. Though it's a two-way street, and some contributors could also be more cooperative also. Walter and a few others have been quite gracious to me [3] [4]. I've tried to pay that forward and help other contributors find their "in", but I'm still not able to review and make decisions about many things, so I'm only of limited help. I don't think others have been treated as well. Mike [0] - https://issues.dlang.org/show_bug.cgi?id=14100 - Link in that issue no longer exists, but let's just say the user wasn't happy with D [1] - https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Amarler8997+is%3Aclosed [2] - https://github.com/dlang/dmd/pull/8378 [3] - https://github.com/dlang/dmd/pull/7395#issuecomment-349200847 [4] - https://github.com/dlang/dmd/pull/7055#issuecomment-320006283
Re: Engine of forum
On Wednesday, 22 August 2018 at 23:53:46 UTC, H. S. Teoh wrote: On Wed, Aug 22, 2018 at 04:24:17PM -0700, Walter Bright via Digitalmars-d wrote: On 8/22/2018 10:28 AM, H. S. Teoh wrote: > I don't argue against the usefulness of the features that > github provides, but I'm also wary of the fact that it's > basically a walled garden -- there's no simple way I know of > to extract data like pull requests, comments, > cross-references, etc.. I mean, it's *possible* to write a > web crawler that does just that, but such functionality is > second-class, and one might argue, that it is possible at > all is merely a happy accident, since github's very design > seems to be geared at drawing people to centralize > everything on github. It's not quite at the point of vendor > lock-in, but it's certainly uncomfortably close, in my view. As for github comments, they get echoed to me as emails. So I have an email archive of them. That's good to know. Still, an export function that will give you your data in some computer-parseable format would have been nice. T They have an API for taht, and it looks like people have made programs to create backups of it with the api. https://developer.github.com/v3/ https://hackage.haskell.org/package/github-backup
Re: Engine of forum
On Wed, Aug 22, 2018 at 04:24:17PM -0700, Walter Bright via Digitalmars-d wrote: > On 8/22/2018 10:28 AM, H. S. Teoh wrote: > > I don't argue against the usefulness of the features that github > > provides, but I'm also wary of the fact that it's basically a walled > > garden -- there's no simple way I know of to extract data like pull > > requests, comments, cross-references, etc.. I mean, it's *possible* > > to write a web crawler that does just that, but such functionality > > is second-class, and one might argue, that it is possible at all is > > merely a happy accident, since github's very design seems to be > > geared at drawing people to centralize everything on github. It's > > not quite at the point of vendor lock-in, but it's certainly > > uncomfortably close, in my view. > > As for github comments, they get echoed to me as emails. So I have an > email archive of them. That's good to know. Still, an export function that will give you your data in some computer-parseable format would have been nice. T -- Why can't you just be a nonconformist like everyone else? -- YHL
Re: Engine of forum
On 8/22/2018 10:28 AM, H. S. Teoh wrote: I don't argue against the usefulness of the features that github provides, but I'm also wary of the fact that it's basically a walled garden -- there's no simple way I know of to extract data like pull requests, comments, cross-references, etc.. I mean, it's *possible* to write a web crawler that does just that, but such functionality is second-class, and one might argue, that it is possible at all is merely a happy accident, since github's very design seems to be geared at drawing people to centralize everything on github. It's not quite at the point of vendor lock-in, but it's certainly uncomfortably close, in my view. As for github comments, they get echoed to me as emails. So I have an email archive of them.
[OT] "I like writing in D" - Hans Zimmer
You may already know that from youtube. It seems D starts getting traction even among musicians: https://www.youtube.com/watch?v=yCX1Ze3OcKo&feature=youtu.be&t=64 That really put a smile on my face :D And it would be a nice example of a D advertising campaign ;) Cheers, Piotrek
Re: [OT] Leverage Points
On Wednesday, 22 August 2018 at 13:17:00 UTC, Kagamin wrote: On Monday, 20 August 2018 at 03:57:10 UTC, John Carter wrote: * Choice. ie. Programmers _want_ to use it, not are constrained to use it. * For programming activity, not new projects. ie. The era of vast tracts of green field programming is long gone. We're mostly in the era tinker toys and tidying. That's a matter of choice, some are tidying, but there's a lot of green field programming even in C, and new languages are all green fields. I suspect if you actually lean of the shoulder of the vast majority programmers earning their daily bread, they aren't writing a brand new program... they enhancing, and fixing an existing one. There is a big difference between "Doing a lot of" and "Being Good at". That's why you can't be tidying all the time, you can improve, but can't become good this way. Oh, I would argue it's the best way. Or this wouldn't be funny http://bonkersworld.net/building-software By tidying I mean refactoring legacy code that is way too large and complex to rewrite all at once. Nobody is going to deep refactoring; example: C/C++ (well, you mention them too) and pretty much everything. And it's that large because it accumulated garbage and rewrite will cut it to a manageable size; example: s2n (fun fact: it's written in C, but uses slices for safety just like D). Whenever I see a rewrite which claims it has made things so wondrously simpler / better, closer inspection reveals it does wondrously less, and supports wondrously less legacy cruft. Thus I do not believe these "experiments" have isolated the effect deleting unneeded or little used features and support for legacy platforms, vs the effect of rewriting vs refactoring. Nobody is going to deep refactoring That I believe could be the paradigm shifting advantage of D. Every time I have written a refactoring or code analysis tool for C or C++, the preprocessor has amplified the complexity of my task by orders of magnitude. And every transformation I might propose it is incredibly hard to guarantee that it is safe and behaviour preserving, a sentiment echo'd by every optimization pass writer for C/C++.
Re: Using a C++ class in a D associative array
On Wednesday, 22 August 2018 at 19:25:40 UTC, Jacob Carlborg wrote: This could be solved, I think, with having "TypeInfo.getHash" a template taking the actual type and not void*. That template can then inspect if the passed type is a D class or any other type of class and act accordingly. It could be simpler (and slower ;)) by using `m_flags & ClassFlags.isCPPclass`.
Re: Using a C++ class in a D associative array
On 2018-08-21 02:07, kinke wrote:
On Monday, 20 August 2018 at 22:16:09 UTC, Jacob Carlborg wrote:
At the third line there's a call from object.TypeInfo_Class.getHash. I
looked up to see what the "getHash" method is doing in druntime [2],
the method looks like this:
override size_t getHash(scope const void* p) @trusted const
{
auto o = *cast(Object*)p;
return o ? o.toHash() : 0;
}
I guess the compiler uses the AA key type's TypeInfo, which is available
for extern(C++) classes too. The TypeInfo_Class.getHash() then uses the
dynamic type via virtual call, (wrongly) assuming it's always a D class.
For an extern(C++) class, it will either call another virtual function
(no inherited virtual functions from Object), what you were seeing, or
attempt to call... something. ;)
All this just compiled without any error or warnings. No runtime
exceptions or asserts were triggered. I just got a really weird behavior.
This is somewhat special due to the common TypeInfo.getHash() signature
for all kinds of types, and so just taking a hairy void* pointer to the
byte/real/static array/AA/object/… to be hashed.
Polishing C++ interop with extern(C++) classes (matching ctors/dtors,
mixed class hiearchies, ability to easily
allocate/construct/destruct/free on the other language side etc.) has
started with v2.081 and is still on-going; there are probably more
places in druntime silently assuming a D class.
This could be solved, I think, with having "TypeInfo.getHash" a template
taking the actual type and not void*. That template can then inspect if
the passed type is a D class or any other type of class and act accordingly.
--
/Jacob Carlborg
Re: core.attribute - Remove friction for compiler attributes
On Tuesday, 20 October 2015 at 07:57:29 UTC, Marco Leise wrote:
For a while now GDC and LDC have supported a variety of their
backend's attributes, like inlining or compiling a specific
function with SSE4 in an otherwise generic x64 build.
I think we should unify those into a common core.attribute,
either aliasing or replacing the vendor specific symbols. They
don't need to be functional immediately. There are two things
that I see need to be discussed.
I couldn't agree more.
It's awkward having to write such boilerplate code just to get
something as common as @inline to compile across compilers.
Another example:
https://github.com/JinShil/stm32f42_discovery_demo/blob/d61819015/source/runtime/object.d#L16
And for embedded applications @used, @section(".xy") and @weak
would also be useful.
Re: concurrency call to arms
On Wed, Aug 22, 2018 at 05:56:09PM +0100, Russel Winder via Digitalmars-d wrote: > On Thu, 2018-08-16 at 16:33 -0700, H. S. Teoh via Digitalmars-d wrote: > […] > > I read both articles, and am quite impressed by the revolutionary > > way of looking at concurrency. It provides a clean(er) abstraction > > that can be reasoned about much more easily than currently prevalent > > models of concurrency. Seems it would fit right in with D's > > message-based concurrency communication model. > > I found the assumptions about what goroutines were to be wrong. Yes > there is an interesting structure built using Python context managers > to manage tasks executed by time division multiplexing, but is that > really needed since the current systems work just fine if you have > threadpools and multiple executing threads – as Java, Go, etc. have > but Python does not. I approached the article from a language-independent viewpoint. While I know a little bit of Python, I wasn't really very interested in the Python-specific aspects of the article, nor in the specific implementation the author had written. What caught my interest was the concept behind it -- the abstraction for concurrent/parallel computation that is easy to reason about, compared to other models. The main innovative idea, IMO, is the restriction of parallel/concurrent processing to the lifetime of an explicit object, in this case, a "nursery". (TBH a better term could have been chosen, but that doesn't change the underlying concept.) More specifically, the lifetime of this object can in turn be tied to a lexical scope, which gives you an explicit, powerful way to manage the lifetime of child processes (threads, coroutines, whatever), as opposed to the open-endedness of, say, spawning a thread that may run arbitrarily long relative to the parent thread. This restriction does not limit the expressive power of the abstraction -- it "gracefully degrades" to current open-ended models if, for example, you allocate a nursery on the heap and spawn child processes / threads / etc. into it. However, by restricting the open-endedness of child (process, thread, ...) lifetime, it gives you the ability to reason about control flow in a much more intuitive way. It restores the linearity of control flow in a given block of code (with the well-defined exception if a nursery was explicitly passed in), making it it much easier to reason about. Unless you're explicitly passing nurseries around, you no longer have to worry about whether some function you call in the block might spawn new processes that continue running after the block exits. You no longer need to explicitly manage shared resources and worry about whether resource X could be released at the end of the block. And so on. Even in the more complex case where nurseries are being passed around, you can still reason about the code with relative ease by examining the lifetime of the nursery objects. You no longer have to worry about the case where background processes continue running past the lifetime of the main program (function, block, etc.), or manually keeping track of child processes so that you can sync with them. Once you have this new way of thinking about concurrent processing, other possibilities open up, like returning values from child processes, propagating exceptions, cancellation, etc.. (Cancellation may require further consideration in non-Python implementations, but still, the model provides the basis for a cleaner approach to this than open-ended models allow.) […] > > Indeed. It certainly seems like a promising step toward addressing > > the nasty minefield that is today's concurrent programming models. > > I'd say processes and channels works just fine. What is this really > providing outside the Python sphere? (Also Javascript?) [...] Functionally, not very much. Readability and understandibility-wise, a lot. And that is the point. I personally couldn't care less what it contributes to Python, since I don't use Python very much outside of SCons, and within SCons concurrent processing is already taken care of for you and isn't an issue the user needs to worry about. So in that sense, Trio isn't really relevant to me. But what I do care about is the possibility of a model of concurrency that is much more easily understood and reasoned about, regardless of whether the underlying implementation uses explicit context-switching, fibres, threads, or full-blown processes. Basically, what we're talking about is the difference between a control flow graph that's an arbitrarily-branching tree (open-ended concurrency model with unrestricted child lifetimes: one entry point, arbitrary number of exits), vs. a single-entry single-exit graph where every branch eventually rejoins the parent (nursery model). Having an arbitrarily branching control flow means many concepts don't work, like return values, propagating exceptions back to the parent, managing child lifetimes, etc.. Having well-de
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote: Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. Yea, I agree, the negatives are not really negative Walter not matter how smart he is, he is one man who can work on the so many things at the same time Its a chicken and egg situation, D needs more core contributors, and to get more contributors it needs more users, and to get more users it need more core contributors
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html Pretty positive overall, and the negatives he mentions are fairly obvious to anyone paying attention. D would really benefit from a project manager, which I think Martin Nowak has tried to do, and which the companies using D and the community should get together and fund as a paid position. Maybe it could be one of the funding targets for the Foundation. If the job was well-defined, so I knew exactly what we're getting by hiring that person, I'd contribute to that.
Re: Engine of forum
On Wed, Aug 22, 2018 at 04:06:38PM +, Neia Neutuladh via Digitalmars-d wrote: [...] > I'm a little paranoid about centralized services like Github. I'd > prefer a federated service for source control / project management, > where you could easily fork projects from my server to yours and send > back pull requests. Then there would be no extra cost for hosting > your own vs using an existing instance. In fact, git itself was designed with such a decentralized usage pattern in mind. Ironically, people have rebuilt centralized platforms on top of it, and even to the point of building walled gardens like github. I don't argue against the usefulness of the features that github provides, but I'm also wary of the fact that it's basically a walled garden -- there's no simple way I know of to extract data like pull requests, comments, cross-references, etc.. I mean, it's *possible* to write a web crawler that does just that, but such functionality is second-class, and one might argue, that it is possible at all is merely a happy accident, since github's very design seems to be geared at drawing people to centralize everything on github. It's not quite at the point of vendor lock-in, but it's certainly uncomfortably close, in my view. > I've been low-key thinking about making a federated github, one where > exporting your data is as simple as a `git clone; git submodule update > --init`. Probably nothing will come of it, though. That would be more in line with the decentralized design of git. I would welcome such a platform, if it ever materializes. T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
Re: concurrency call to arms
On Fri, 2018-08-17 at 18:36 +1200, rikki cattermole via Digitalmars-d wrote: > After reading the article I can say, it isn't any better than async > and > await for dependencies. You still need an event loop. > > […] Or a work stealing threadpool. Event loops are only really needed in contexts that must be single threaded. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: concurrency call to arms
On Thu, 2018-08-16 at 16:33 -0700, H. S. Teoh via Digitalmars-d wrote: > […] > I read both articles, and am quite impressed by the revolutionary way > of > looking at concurrency. It provides a clean(er) abstraction that can > be > reasoned about much more easily than currently prevalent models of > concurrency. Seems it would fit right in with D's message-based > concurrency communication model. I found the assumptions about what goroutines were to be wrong. Yes there is an interesting structure built using Python context managers to manage tasks executed by time division multiplexing, but is that really needed since the current systems work just fine if you have threadpools and multiple executing threads – as Java, Go, etc. have but Python does not. […] > > Indeed. It certainly seems like a promising step toward addressing > the > nasty minefield that is today's concurrent programming models. I'd say processes and channels works just fine. What is this really providing outside the Python sphere? (Also Javascript?) > […] -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: concurrency call to arms
On Thu, 2018-08-16 at 20:30 +, John Belmonte via Digitalmars-d wrote: > This is actually not about war; rather the peace and prosperity > of people writing concurrent programs. > > (Andrei, I hope you are reading and will check out > https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ > On skimming this, I get the feeling the author doesn't really understand goroutines and channels. Actually I am not entirely sure the person understands concurrency and parallelism. > and > https://vorpus.org/blog/timeouts-and-cancellation-for-humans/) > > Recently I've been working with Trio, which is a Python async > concurrency library implementing the concepts described in the > articles above. A synopsis (Python): Have you tried asyncio in the Python standard library? Is Trio better? > with open_task_container() as container: > container.start_task(a) > container.start_task(b) > await sleep(1) > container.start_task(c) > # end of with block > > # program continues (tasks a, b, c must be completed)... Assuming a, b, and c run in parallel and this is just a nice Pythonic way of ensuring join, this is fairly standard fork/join thread pool task management – except Python is single threaded so the above is time division multiplexing of tasks. std.parallelism can already handle this sort of stuff in D as far as I know. > The point is that tasks started in the container's scope will not > live past the scope. Scope exit will block until all tasks are > complete (normally or by cancellation). If task b has an > exception, all other tasks in the container are cancelled. Use of scope like this is a good thing, and something GPars, Quasar, and others supports. Using a context manager in Python is clearly a very Pythonic way of doing it. > What this means is that task lifetimes can be readily understood > by looking at the structure of a program. They are tied to > scoped blocks, honor nesting, etc. > > Similar for control of timeouts and cancellation: > > with fail_after(10): # raise exception if scope not > completed in 10s > reply = await request(a) > do_something(reply) > reply2 = await request(b) > ... > > These are novel control structures for managing concurrency. > Combining this with cooperative multitasking and explicit, > plainly-visible context switching (i.e. async/await-- sorry > Olshansky) yields something truly at the forefront of concurrent > programming. I mean no callbacks, almost no locking, no > explicitly maintained context and associated state machines, no > task lifetime obscurity, no manual plumbing of cancellations, no > errors dropped on the floor, no shutdown hiccups. I'm able to > write correct, robust, maintainable concurrent programs with > almost no mental overhead beyond a non-concurrent program. I'd disagree with them being novel control structures. The concepts have been around for a couple of decades. They have different expressions in different languages. Python's context manager just makes it all very neat. Clearly getting rid of the nitty-gritty management detail of concurrency and parallelism is a good thing. Processes and channels have been doing all this for decades, but have only recently become fashionable – one up to Rob Pike and team. I've not followed async/await in C# but in Python it is a tool for concurrency but clearly not for parallelism. Sadly async/await has become a fashion that means it is being forced into programming languages that really do not need it. Still there we see the power of fashion driven programming language development. > Some specimens (not written by me): > #1: the I/O portion of a robust HTTP 1.1 server > implementation in about 200 lines of code. > https://github.com/python-hyper/h11/blob/33c5282340b61ddea0dc00a16b6582170d822d81/examples/trio-server.py > #2: an implementation of the notoriously difficult "happy > eyeballs" networking connection algorithm in about 150 lines of > code. > https://github.com/python-trio/trio/blob/7d2e2603b972dc0adeaa3ded35cd6590527b5e66/trio/_highlevel_open_tcp_stream.py > > I'd like to see a D library supporting these control structures > (with possibly some async/await syntax for the coroutine case). > And of course for vibe.d and other I/O libraries to unify around > this. Kotlin, Java, etc. are all jumping on the coroutines bandwagon, but why? There is no actual need for these given you can have blocking tasks in a threadpool with channels already. > I'll go out on a limb and say if this could happen in addition to > D addressing its GC dirty laundry, the language would actually be > an unstoppable force. Why? Are coroutines with language syntax support really needed? And whilst Go is obsessively improving it's GC so as to make it a non- issue to any performance arguments, it seems this is an insoluble
Re: Engine of forum
On Wednesday, 22 August 2018 at 15:17:36 UTC, Jesse Phillips wrote: It is weird that you make loosing current and historical pull requests is minor It would be disruptive. However, work could resume rather quickly. The disruption would be reduced if we had a periodic job set up to mirror github pull requests. There is at least one export tool, but it seems to get only the titles and not the comments or patches. compared to: * Having all the data readily available for search engines to have archived (today, not tomorrow). * Having an established forum/newsgroup readily available to handle the load of new questions. I just don't see data retention and recovery for StackOverflow to be a concern for making such a choice. Even if it did take weeks or months to host the historical data, risk should be weighed against possible benefit from visibility and growth from heavily using StackOverflow. And similarly, the choice of Github instead of a self-hosted system is weighed against requiring people to sign up with a private gitlab instance. Also similarly, the disruption would be reduced if we had a periodic job set up to handle long-term stackoverflow unavailability in advance. I'm a little paranoid about centralized services like Github. I'd prefer a federated service for source control / project management, where you could easily fork projects from my server to yours and send back pull requests. Then there would be no extra cost for hosting your own vs using an existing instance. I've been low-key thinking about making a federated github, one where exporting your data is as simple as a `git clone; git submodule update --init`. Probably nothing will come of it, though.
Re: Engine of forum
On Wednesday, 22 August 2018 at 05:05:48 UTC, Neia Neutuladh wrote: The dlang bugzilla and forum are both hosted on dlang-specific servers. If they go down, it's easy to get a replica and get back up and running in a few hours. Same with the wiki. If github went down or banned the dlang org, we'd lose in-progress pull requests and the history of pull request comments. Aside from that, we would be up and running on gitlab or what have you in hours. If Stack Overflow went down, we'd have to find an alternative, and then we'd have to figure out how to import that data. That could take weeks. And it will happen eventually. It is weird that you make loosing current and historical pull requests is minor compared to: * Having all the data readily available for search engines to have archived (today, not tomorrow). * Having an established forum/newsgroup readily available to handle the load of new questions. I just don't see data retention and recovery for StackOverflow to be a concern for making such a choice. Even if it did take weeks or months to host the historical data, risk should be weighed against possible benefit from visibility and growth from heavily using StackOverflow.
Re: Friends don't let friends use inout with scope and -dip1000
On Wednesday, 22 August 2018 at 14:05:10 UTC, Steven Schveighoffer wrote: But that's not valid dip1000 code. If you call it, it should give a compiler error (r *does* escape its scope). When I complained about C++ safety to my C++ programmer colleague, he told me that the compiler just compiles what's written. On one hand I can understand what he wanted to say, but the wording is still hilarious and fits C++ very well. What I like in D is that if it's written doesn't mean that it will compile: invalid code should be rejected.
Re: [OT] Leverage Points
On Wednesday, 22 August 2018 at 13:28:37 UTC, Kagamin wrote: On Monday, 20 August 2018 at 08:31:15 UTC, Dave Jones wrote: That's what Im trying to say. Im sure posts like that are popular within the D community but they are not going to make much headway bringing new users in. We had "D parser smokes the competition" posts. Unfortunately, with all the D parsers that smoked the competition, we are mostly stuck with std.xml (dxml might changed this) and std.json, because those other projects never made it into the stdlib for one reason for another (not being 100% range based, not supporting XYZ memory allocator).
Re: Friends don't let friends use inout with scope and -dip1000
On 8/22/18 4:17 AM, Kagamin wrote:
On Tuesday, 21 August 2018 at 14:04:15 UTC, Steven Schveighoffer wrote:
I would guess it's no different than other inferred attributes. I
would also guess that it only gets promoted to a return parameter if
it's actually returned.
If we can't have properly typed parameters, it feels like it has
potential to prevent some patterns.
But scope is not part of the type, nor is return. One of my biggest
concerns about dip1000 is that the "scope-ness" or "return-ness" of a
variable is hidden from the type system. It's just the compiler doing
flow analysis and throwing you an error when it can't work the thing
out. I'm more worried about not being able to express the flow in a way
that the compiler understands, and having it complain about things that
are actually safe.
This prevents automatic scope promotion:
template escape(T)
{
int[] escape1(scope int[] r)
{
return r;
}
alias escape=escape1;
}
But that's not valid dip1000 code. If you call it, it should give a
compiler error (r *does* escape its scope).
-Steve
Re: Is @safe still a work-in-progress?
On 8/22/18 5:23 AM, Walter Bright wrote: On 8/21/2018 6:07 PM, Mike Franklin wrote: The proposed idea wants to make the first parameter, if it's `ref`, special. This is because Phobos is written with functions of the form: void put(sink, parameters...) which corresponds to: sink.put(parameters...) The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax. > Why not the first `ref` parameter regardless of whether it's the absolute first in the list. Why not the last `ref` parameter? Why not all `ref` parameters? Good question. If this fairly restricted form solves the problems, then there is no need for the more flexible form. Things can always be made more flexible in the future, but tightening things can be pretty disruptive. Hence, unless there is an obvious and fairly strong case case for the flexibility, then it should be avoided for now. What about: size_t put(sink, parameters...) Does this qualify as the sink being the "return" type? Obviously the real return can't contain any references, so it trivially can be ruled out as the destination of any escaping parameters. Or how about a member function that takes a ref parameter? Is `this` the "return" or is the ref parameter the "return"? My problem with the idea is that it is going to seem flaky -- we are using convention to dictate what is actually the return parameter, vs. what semantically happens inside the function. It's going to confuse anyone trying to do it a different way. I've experienced this in the past with things like toHash, where if you didn't define it with the exact signature, it wouldn't actually be used. I realize obviously, that `put` is already specified. But as I said in the bug report, we should think twice about defining rules based solely on how Phobos does things, and calling that the solution. As for things being made "more flexible in the future" this basically translates to code breakage. For example, if you are depending on only the first parameter being considered the "return" value, and all of a sudden it changes to encompass all your parameters, your existing code may fail to compile, even if it's correctly safe and properly annotated. I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work. I think it's a very worthy goal to make Phobos work, and a great proof of concept for dip1000's veracity. However, one-off rules just to make it work with existing code go against that goal IMO. Rules that stand on their own I think will fare better than ones that are loopholes to allow existing code to compile. -Steve
Re: [OT] Leverage Points
On Monday, 20 August 2018 at 08:31:15 UTC, Dave Jones wrote: That's what Im trying to say. Im sure posts like that are popular within the D community but they are not going to make much headway bringing new users in. We had "D parser smokes the competition" posts.
Re: [OT] Leverage Points
On Monday, 20 August 2018 at 03:57:10 UTC, John Carter wrote: * Choice. ie. Programmers _want_ to use it, not are constrained to use it. * For programming activity, not new projects. ie. The era of vast tracts of green field programming is long gone. We're mostly in the era tinker toys and tidying. That's a matter of choice, some are tidying, but there's a lot of green field programming even in C, and new languages are all green fields. There is a big difference between "Doing a lot of" and "Being Good at". That's why you can't be tidying all the time, you can improve, but can't become good this way. By tidying I mean refactoring legacy code that is way too large and complex to rewrite all at once. Nobody is going to deep refactoring; example: C/C++ (well, you mention them too) and pretty much everything. And it's that large because it accumulated garbage and rewrite will cut it to a manageable size; example: s2n (fun fact: it's written in C, but uses slices for safety just like D).
Dicebot on leaving D: It is anarchy driven development in all its glory.
Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 11:02:00 UTC, Seb wrote: No, it's behind a flag, so you can't really say that we're shipping it as "production ready release". The changes to Phobos are not behind a flag. We're making changes to Phobos in the release branch to accommodate a draft/experimental/choose-your-adjective feature. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote: On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote: But what bothers me the most... Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`: https://github.com/dlang/DIPs/blob/master/DIPs/README.md What the heck is going on here? We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal? No, it's behind a flag, so you can't really say that we're shipping it as "production ready release". In fact I think we should have a hell of a lot more of such experimental flags. This would allow us to be able to merge things quickly, and gain real-world feedback and testing on complicated matters instead of PRs stalling to death in the queue. For reference, Rust has currently 148 opt-in experimental language features: https://doc.rust-lang.org/unstable-book/index.html
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:05:13 UTC, Walter Bright wrote: On 8/21/2018 8:58 PM, Nicholas Wilson wrote: On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote: The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`. Another way to think about it is this: S s; return &s; We all know that is an error. The idea is to have a way to express that for: S s; return s.foo(); and: S s; return foo(&s); so that the compiler knows that the return value of foo() is attached to the lifetime of s. Pretty much everything flows from that. Would the guideline below be correct? "Add scope to every non-template member function that isn't meant to escape this and add return to every non-template member function that returns all or part of `this` by pointer or ref if you want the compiler to check that nothing gets escaped in @safe code."
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
dip1000 has been around for two years, and its predecessor
dip25 several years now. Plenty of time for anyone to comment
and/or propose something better.
Part of the problem is that the implementation keeps changing
without keeping the documentation in sync. For example you're
implementing all of these inference rules without documenting
them:
https://github.com/dlang/dmd/pull/8346
https://github.com/dlang/dmd/pull/8408
I asked you about, instead of inferring the attributes, allowing
users to add such logic themselves:
void foo(T)(T x)
if (__traits(isPointer, T)) { T = scope T; }
{ }
But, then the PR got rubber-stamped, and now here we are.
Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote: I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work. There's a good chance you'll get your PR merged when it's documented and vetted, then you'll be able to make it work for Atila. The only think holding it up is you. I'm not asking for much. Sufficiently document the idea, open it up for comment and Q & A, transfer the documentation to the spec to accompany the DMD implementation PR. Assuming there's no major flaws in the design, it should get merged. Mike P.S. Actually, I've been trying to document it myself, since you don't seem willing to, but it's going to take me a lot longer to figure out what's in your head than it would take you.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote: The proposed idea wants to make the first parameter, if it's `ref`, special. This is because Phobos is written with functions of the form: void put(sink, parameters...) which corresponds to: sink.put(parameters...) The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax. Makes perfect sense. This is the kind of stuff I'd like you to put in a formal document and present to us as an RFC along with your PR. Then transfer that information to the spec to accompany the DMD PR, after you've received feedback. Mike
Re: Is @safe still a work-in-progress?
On 8/21/2018 6:07 PM, Mike Franklin wrote: The proposed idea wants to make the first parameter, if it's `ref`, special. This is because Phobos is written with functions of the form: void put(sink, parameters...) which corresponds to: sink.put(parameters...) The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax. > Why not the first `ref` parameter regardless of whether it's the absolute first in the list. Why not the last `ref` parameter? Why not all `ref` parameters? Good question. If this fairly restricted form solves the problems, then there is no need for the more flexible form. Things can always be made more flexible in the future, but tightening things can be pretty disruptive. Hence, unless there is an obvious and fairly strong case case for the flexibility, then it should be avoided for now. But what bothers me the most is I think it's missing the bigger picture: D needs a way to annotate lifetimes. Maybe `scope` and `return` with weird conditions based on the order of parameters and their attributes are the way to go. Maybe there's another way that hasn't yet been considered. Put together a thorough description of the proposal, justify it, ask the larger community for comment, vet it, and document it. At least that's what it's going to take to get me to take action on the PR. dip1000 has been around for two years, and its predecessor dip25 several years now. Plenty of time for anyone to comment and/or propose something better. --- I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work.
Re: Is @safe still a work-in-progress?
On 8/21/2018 8:58 PM, Nicholas Wilson wrote: On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote: The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`. Another way to think about it is this: S s; return &s; We all know that is an error. The idea is to have a way to express that for: S s; return s.foo(); and: S s; return foo(&s); so that the compiler knows that the return value of foo() is attached to the lifetime of s. Pretty much everything flows from that.
Re: Is @safe still a work-in-progress?
On 8/21/2018 2:17 PM, Atila Neves wrote:
Well, no. The syntax isn't the same for member functions. The examples from the
actual DIP don't compile. There it says:
---
scope can be applied to function return values (even though it is not a type
qualifier). It must be applied to the left of the declaration, in the same way
ref is:
scope int* foo(); // applies to return value
Except:
---
struct MyStruct { scope int* foo() scope; }
foo.d(1): Error: redundant attribute scope
---
Meaning the first `scope` actually applies to `this`. Writing this out as a
non-member function won't help me declare member functions!
I still don't know how to return a ref/pointer that's scoped. And I thought I'd
written code that did that. Maybe I did. I'm very confused.
Here's how you make it work:
---
@safe:
struct MyStruct {
ref int foo() return;
int* bar() return;
}
ref int sun() {
MyStruct s;
return s.foo(); // returning s.foo() escapes a reference to local variable s
}
int* moon() {
MyStruct s;
return s.bar(); // returning s.bar() escapes a reference to local variable s
}
---
In effect, the 'return' on 'foo()' says:
The return value of foo() contains the address of 'this', and if the return
escapes the scope of what 'this' is a ref to, then it's an error.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 03:58:42 UTC, Nicholas Wilson wrote: On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote: The problem is that the code we write doesn't deal directly with pointers - see the recent confusion in this forum over where `scope` on the left applies to the `this` pointer or the one returned by the member function. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. The way I think about it is if you have a function that takes a pointer, any pointer, and either returns it or a pointer derived from it (dereferencing or indexing) that argument must be marked `return`. In your case it was a pointer derived from `this` so `return` must be applied to `this`. I guess my problem is that DIP1000 talks about returning scope values and they don't seem to actually exist in the implementation.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote: On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis wrote: The reality of the matter is that the DIP system is a formal way to propose language changes in order to convince Walter and Andrei that those changes should be implemented, whereas if Walter or Andrei writes the DIP, they're already convinced. This isn't a democracy. Walter is the BDFL, and it's his call. So, I really don't think that it's hypocritical Walter and Andrei need to have their ideas vetted by the community, not in an effort to convince anyone, but for quality assurance, to ensure they're not overlooking something. It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. The formal DIP process was put in place after DIP1000. I would even daresay that the process was put in place because of the issue with DIP1000 (the rigorously checked DIP's are all >1000 for that reason).
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 14:04:15 UTC, Steven Schveighoffer
wrote:
I would guess it's no different than other inferred attributes.
I would also guess that it only gets promoted to a return
parameter if it's actually returned.
If we can't have properly typed parameters, it feels like it has
potential to prevent some patterns.
This prevents automatic scope promotion:
template escape(T)
{
int[] escape1(scope int[] r)
{
return r;
}
alias escape=escape1;
}
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote: Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`: https://github.com/dlang/DIPs/blob/master/DIPs/README.md What the heck is going on here? We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal? Furthermore, I find it hypocritical that some of us are put through a disproportionately burdensome DIP process requiring thorough documentation, multiple peer reviews, excessive delays, and judgment that defaults to "no" for some of the most minute changes to the language, but a game-changing feature like DIP 1000 can just be amended on a whim. +1, For valuable contributors like you, it's far from friendly. Friendly atmosphere increases creativity. Although, for an industrial-level language, it should be careful to add many features (A core engine that can simulate a lot of easy to use sugars is important, for those potential hackers. )
