Re: D, Parasail, Pascal, and Rust vs The Steelman
On 22/03/18 16:45, Radu wrote: On Thursday, 22 March 2018 at 11:58:02 UTC, Shachar Shemesh wrote: On 22/03/18 12:28, Meta wrote: On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote: [...] "The central failure of the language is the myopic focus on the affine typing solution to heap allocation and thread safety. The creators do not seem to realise that other solutions already exist, and that dynamic memory allocation is not the only safety issue a programmer has to cope with." Interesting that the author's criticism of Rust lines up very closely with Andrei's. Spoken on the forum for a language that has still not managed to make sure that a destructor actually gets called every time an object is destroyed. Shachar Shaming this one? https://issues.dlang.org/show_bug.cgi?id=14246#c6 Indeed, that sucks big time! There is hope. We finally merged a PR that removes the changelog that erroneously claimed this issue was resolved. https://github.com/dlang/dlang.org/commit/45ca5e35d3de824e104c3049083eb23fa03775c5 Progress!! Shachar
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote: I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... A 3rd example (https://github.com/dlang/dmd/pull/8346) to throw a little more salt on the wound. The DIP25/1000 rabbit hole is deepening behind the curtain. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote: Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request. I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... Yet I and others have to go through the DIP process for much less significant changes to the language, and rightly so: https://github.com/dlang/dmd/pull/7310 https://github.com/dlang/dmd/pull/7079 All I want to see from Walter is: 1) a sufficiently documented proposal for his idea 2) an RFC from the community 3) a PR to the spec documenting the final design I don't think that's too much to ask. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote: It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. Sorry, that was poorly stated and conveyed the wrong intent. It should read: It is hypocritical an arrogant to believe that only our ideas should require thorough documentation and scrutiny. Mike
Re: Engine of forum
On Tuesday, 21 August 2018 at 22:00:31 UTC, Jesse Phillips wrote: On Tuesday, 21 August 2018 at 19:25:14 UTC, Walter Bright wrote: With the NNTP, git, and bugzilla, we all have backups under our control. I just don't see why it is a concern[1]: "So we set out to look for a new home for our data dumps, and today we’re happy to announce that the Internet Archive has agreed to host them: The Stack Exchange Data Dump at the Internet Archive[2]" 1. : https://stackoverflow.blog/2014/01/23/stack-exchange-cc-data-now-hosted-by-the-internet-archive/ 2. https://archive.org/details/stackexchange 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.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote: 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 judgement 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. DIP 1000 is in a bit of limbo at the moment. When I took over the process from Mihails, he told me it was stalled and that the proposal did not match the implementation. So I haven't touched it, which is why it's still marked as Draft. At some point, Walter will revise it to match the implementation and then we'll discuss how to handle it. Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request.
Re: Is @safe still a work-in-progress?
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. Mike
Re: Is @safe still a work-in-progress?
On Tuesday, August 21, 2018 8:18:15 PM MDT Mike Franklin via Digitalmars-d 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? > > 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 judgement 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. 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, but I also do think that DIP 1000 probably should have gone through more peer review. From what I can tell, outside of the simple cases, pretty much everyone has a really hard time understanding it. The situation will likely improve once Phobos properly supports it, and you can more reasonably use it, but the whole thing defnitely seems to be overly complicated given what it's supposed to be doing and what benefits you get from it. Personally, I think that it seems pretty reasonable as long as user-defined types don't get involved, but once they do, it's a mess. - Jonathan M Davis
Re: Is @safe still a work-in-progress?
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`.
Re: Is @safe still a work-in-progress?
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? 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 judgement 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. Mike
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote: I don't have merge rights. I took a look anyway and it mostly looks ok, but I'm not familiar enough with that part of the codebase. It's not the implementation that's preventing it from being merged. It's the idea itself, weak rationale, lack of peer review, lack of consideration for alternatives, and lack of documentation supporting it. It reeks of "designed on a whim to quickly patch some oversight in the design DIP1000 while trying to get Phobos to compile with -dip1000". With the proposed idea, order of parameters matters. We'll need to establish a convention that return parameters must be declared first, which is opposite of https://dlang.org/phobos/std_algorithm_mutation.html#copy. Is that a good idea? Maybe it is. We haven't vetted the design yet, so I'm not sure. Why haven't we vetted the design? Because there currently isn't one; there's just an informal back-of-the-napkin memo uploaded to a bugzilla entry. The proposed idea wants to make the first parameter, if it's `ref`, special. 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? 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. Or maybe someone else is willing to just rubber stamp it in the interest of expediency. Mike
Re: Engine of forum
On Tuesday, 21 August 2018 at 19:25:14 UTC, Walter Bright wrote: With the NNTP, git, and bugzilla, we all have backups under our control. I just don't see why it is a concern[1]: "So we set out to look for a new home for our data dumps, and today we’re happy to announce that the Internet Archive has agreed to host them: The Stack Exchange Data Dump at the Internet Archive[2]" 1. : https://stackoverflow.blog/2014/01/23/stack-exchange-cc-data-now-hosted-by-the-internet-archive/ 2. https://archive.org/details/stackexchange
Re: Engine of forum
On Tuesday, 21 August 2018 at 21:33:13 UTC, Patrick Schluter wrote: On Tuesday, 21 August 2018 at 06:53:18 UTC, Daniel N wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month. Second that. The 2 big things this forum frontend has, is forcing to snip quotes (go look on realworldtech to see whole threads of quote galore of 400 lines where the answer is just one word) and speed. The thing that comments cannot be edited is also an advantage. This forces to put a little be more thought in them. What about if you accidentially press a button that posts the comment? Why can't syntax formatting be implemented, does anyone disagree that is a useless feature?
Re: Engine of forum
On Tuesday, 21 August 2018 at 06:53:18 UTC, Daniel N wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month. Second that. The 2 big things this forum frontend has, is forcing to snip quotes (go look on realworldtech to see whole threads of quote galore of 400 lines where the answer is just one word) and speed. The thing that comments cannot be edited is also an advantage. This forces to put a little be more thought in them.
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 19:36:39 UTC, Walter Bright wrote:
On 8/21/2018 7:31 AM, 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.
That's what I was saying :-)
The way to deal with this is make a copy of the code, then
rewrite it so it does the exact same thing, but with pointers
and refs only. No member functions, no delegates, no dynamic
arrays. Then it is MUCH MUCH easier to see where the
annotations go.
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.
BTW, the annotations do not break things. The worst that will
happen is the compiler will complain in @safe code that they
are incorrect, and you'll need to fix it or make it @trusted.
The compiler is also pretty good about inferring the correct
annotations, at least for templates and lambdas, which helps
enormously.
In my opinion, the worst that can happen is I successfully
compile my @safe code with -dip1000 and the resulting binary
isn't memory-safe, which is what's been happening to me.
However, dip1000 not working with Phobos is a huge impediment
to success, and so pulling 8504 is critical.
I don't have merge rights. I took a look anyway and it mostly
looks ok, but I'm not familiar enough with that part of the
codebase.
Re: Is @safe still a work-in-progress?
On 8/21/2018 7:31 AM, 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. That's what I was saying :-) The way to deal with this is make a copy of the code, then rewrite it so it does the exact same thing, but with pointers and refs only. No member functions, no delegates, no dynamic arrays. Then it is MUCH MUCH easier to see where the annotations go. Kagamin just told me I needed to use `return` instead of `scope` to get things to work and I'm still not sure why. Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point. I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me. It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on. All good points. But I cannot make any progress when nobody is willing to pull my PRs that improve the situation. https://github.com/dlang/dmd/pull/8504 BTW, the annotations do not break things. The worst that will happen is the compiler will complain in @safe code that they are incorrect, and you'll need to fix it or make it @trusted. The compiler is also pretty good about inferring the correct annotations, at least for templates and lambdas, which helps enormously. However, dip1000 not working with Phobos is a huge impediment to success, and so pulling 8504 is critical.
Re: Engine of forum
On 8/21/2018 7:18 AM, Seb wrote: some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow. My reservation about stackoverflow is it could go dark at any moment, and we'd lose it all. Having critical business data dependent on any third party that has zero commitment or accountability to us is very risky. With the NNTP, git, and bugzilla, we all have backups under our control.
Re: D, Parasail, Pascal, and Rust vs The Steelman
On Wednesday, 21 March 2018 at 16:08:07 UTC, Martin Tschierschke wrote: On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote: An article comparing the above languages as per the DoD language requirements [0]. http://jedbarber.id.au/steelman.html [0] - https://en.wikipedia.org/wiki/Steelman_language_requirements Interesting! Do you understand this: 7H. Formal Array Parameters. The number of dimensions for formal array parameters must be specified in programs and shall be determinable during translation. Determination of the subscript range for formal array parameters may be delayed until invocation and may vary from call to call. Subscript ranges shall be accessible within function and procedure bodies without being passed as explicit parameters. Subscript ranges are not accessible in D or Rust. I do not understand the meaning of "subscript ranges"? Isn't this slicing? I believe this means the range of the underlying array. For arrays on the heap, the D runtime could actually figure this out (using the same mechanism as for calculating .capacity), but of course it can't be done generally.
Re: ./install.sh dmd broken?
On Monday, 13 August 2018 at 17:10:13 UTC, Jonathan Marler wrote: The problem is downloading "install.sh" directly to "~/dlang/install.sh". This causes the install script to think that it has already downloaded the "d-keyring.gpg" so it never downloads it, causing the "invalid signature" error. The fix is to download "install.sh" if the d-keyring is not downloaded, even if install.sh already is. Spot on! Thanks...
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 13:42:31 UTC, Kagamin wrote:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
...
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated
function - it's silently promoted to return parameter. Is this
intended?
I filed a similar bug (it uses return type inference rather than
a template). Walter closed it as invalid:
https://issues.dlang.org/show_bug.cgi?id=17362
wiki.dlang.org confirmation emails marked as spam by gmail
gmail gives the reason: "Lots of messages from k3.1azy.net were identified as spam in the past." Not sure what can be done. Just an FYI.
Re: Engine of forum
On 8/21/18 10:08 AM, Ali wrote: On Tuesday, 21 August 2018 at 05:30:07 UTC, Walter Bright wrote: Ask 10 people, and you'll get 10 different answers on what a better forum would be. Actually I think we can get 8 out of those 10 to agree, rust, ocaml, fsharp, nim, scala, clojure .. all use https://www.discourse.org/ I think this software is nowadays regarded and the best Cool! Does it support an interface on top of a newsgroup server? Priority #1 in these parts. If people leave because of the forum software, changing it won't change that. I also agree with that, most people who leave probably leave for more objective reasons, like that the language doesn't answer their needs, or they didnt find the libraries they needed within the ecosystem etc... But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer , replacing the forum software is a small change, a small win, and I expect small returns. But a small win, is a win On the contrary, many of the regular contributors here, don't give a lick about the forum software, as long as it's primarily backed by the newsgroup server. Many, including myself use the NG server, many others use the mailing list interface. If the NG was ditched, I would have a big problem communicating, as I hate dealing with web forums. The forum software probably could be better in terms of formatting code (see for example vibe.d's forums which are ALSO NG backed and have code formatting features). Other than that, editing posts just doesn't make sense in terms of a mailing list or newsgroup. And it also doesn't make sense in terms of a discussion where things you thought you read mysteriously change. -Steve
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 00:09:03 UTC, Walter Bright wrote: On 8/20/2018 6:46 AM, Steven Schveighoffer wrote: I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows. The way to understand dip1000 is to forget about `this`, arrays, structs, classes, delegates, etc. Just think about pointers - functions that take pointers as arguments, and return pointers. That simplifies things enormously. Once that makes sense, then deconstruct the higher level constructs into pointers, and then you'll see how they work. This is why my presentation does it all in terms of pointers: http://dconf.org/2017/talks/bright.html If you're having trouble understanding a particular example, rewrite it in terms of pointers. If it still is inscrutable, then ask about the pointer version here. (When someone gives me some complex thing and says "I don't understand scope here", I always first rewrite it in terms of pointers. It's the same thing I do with bug reports that use templates - I manually instantiate the templates first.) 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. Also: destructors? Always `scope`? Sometimes? I just add `scope` when the compiler complains at this point. I think it's interesting that when I played with Rust I didn't have problems fighting the borrow checker at all. DIP1000 is supposed to have the same safety without the Rust complications but currently Rust is much easier to understand for me. It doesn't help that the current implementation of -dip1000 doesn't match the document it's supposedly based on.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 11:28:39 UTC, Nicholas Wilson wrote: On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote: On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote: Error: address of variable s assigned to gInt with longer lifetime Looks safe to me. With dmd 2.081.2 on Arch Linux, the code above compiles with no error message. Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it work as intended now? Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? MyStruct is not a template, I presume `return` would get inferred if it was. But yeah that is annoying. At the very least then it should fail to compile if I don't add the relevant annotation, not silently accept buggy code that isn't memory safe but somehow _is_ `@safe`. That's the whole point of -dip1000, no? If I get around it by forgetting something, it's not going to work.
Re: Engine of forum
On Tuesday, 21 August 2018 at 14:18:40 UTC, Seb wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: On Monday, 20 August 2018 at 09:52:01 UTC, Peter Alexander wrote: [...] What are the specific problems solved by using better software? Well, most software projects, have different channels of communications, some use forums, some use newsgroups, some use irc, some use slack, Yep, D also has an active IRC channel (#d) and Slack group (https://forum.dlang.org/post/gidqeijjswgnpveog...@forum.dlang.org). some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow. That would increase the visibility of D as well!
Re: Engine of forum
On Tuesday, 21 August 2018 at 14:08:01 UTC, Ali wrote: [...] But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, Are you serious? This forum software is the most effektive I know. It is also efficient, especially for reading messages. and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer, To what advantage? replacing the forum software is a small change, Arguably... a small win, and I expect small returns. But a small win, is a win It’s not a win in everybody’s minds ;-) I’m not saying that the forum cannot be improved, but to scrap it would be a loss if you ask me.
Re: Engine of forum
On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: On Monday, 20 August 2018 at 09:52:01 UTC, Peter Alexander wrote: What are the specific problems solved or opportunities realised by moving to a real forum? What are the specific problems solved by using better software? Well, most software projects, have different channels of communications, some use forums, some use newsgroups, some use irc, some use slack, Yep, D also has an active IRC channel (#d) and Slack group (https://forum.dlang.org/post/gidqeijjswgnpveog...@forum.dlang.org). some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow.
Re: Engine of forum
On Tuesday, 21 August 2018 at 05:30:07 UTC, Walter Bright wrote: Ask 10 people, and you'll get 10 different answers on what a better forum would be. Actually I think we can get 8 out of those 10 to agree, rust, ocaml, fsharp, nim, scala, clojure .. all use https://www.discourse.org/ I think this software is nowadays regarded and the best If people leave because of the forum software, changing it won't change that. I also agree with that, most people who leave probably leave for more objective reasons, like that the language doesn't answer their needs, or they didnt find the libraries they needed within the ecosystem etc... But what I really meant, is that out of those who leaves, there is possible a very small percentage who left, because they couldnt communicate effectively with the community, and that better communication channels in general ( and a better forum software as an example) could have kept them around for longer , replacing the forum software is a small change, a small win, and I expect small returns. But a small win, is a win
Re: Friends don't let friends use inout with scope and -dip1000
On 8/21/18 9:42 AM, Kagamin wrote:
except for templated functions:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
int[] escape(return int[] r)
{
return r; //ok, just as planned
}
int[] escape(return scope int[] r)
{
return r; //ok, `return scope` reduced to just `return`
}
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated function - it's
silently promoted to return parameter. Is this intended?
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.
As long as the *result* is scoped like the parameter. In the case of the
OP in this thread, there is definitely a problem with inout and the
connection to the return value.
-Steve
Re: Friends don't let friends use inout with scope and -dip1000
...except for templated functions:
int[] escape(scope int[] r)
{
return r; //error, can't return scoped argument
}
int[] escape(return int[] r)
{
return r; //ok, just as planned
}
int[] escape(return scope int[] r)
{
return r; //ok, `return scope` reduced to just `return`
}
int[] escape(T)(scope int[] r)
{
return r; //ok! `scope` silently promoted to `return`
}
You can't have strictly scoped parameter in a templated function
- it's silently promoted to return parameter. Is this intended?
Re: Friends don't let friends use inout with scope and -dip1000
I mean if one method in structure is trusted, other methods need manual verification too.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? In general, safety works per method and doesn't help much in building safe data structures, those are trusted as a whole. EMSI containers are a notable big victim of this thing.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote:
Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does
it work as intended now? Also, if I have to remember to
annotate correctly, surely this is a massive hole in @safe
dip1000?
It thought dip1000 was impenetrable, but if I understand it
(honestly that's a surprise!), `scope` has strict semantics: all
in, nothing out; you don't need to think about lifetime of data
passed to scope parameters, because it doesn't escape anywhere.
If you want to return data extracted from argument, `return`
attribute relaxes scoping rules and allows to return data and
passes scoping properties from argument to return value much like
`inout` does for const.
Without annotation:
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() scope @trusted { free(ints); }
inout(int)* ptr() inout { return ints; }
}
int* gInt;
void f()
{
scope s=MyStruct(10);
gInt=s.ptr;
}
Error: scope variable s assigned to non-scope parameter this
calling MyStruct.ptr
Doesn't let to call method without annotation.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote: On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote: On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote: On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote: Error: address of variable s assigned to gInt with longer lifetime Looks safe to me. With dmd 2.081.2 on Arch Linux, the code above compiles with no error message. Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it work as intended now? Also, if I have to remember to annotate correctly, surely this is a massive hole in @safe dip1000? MyStruct is not a template, I presume `return` would get inferred if it was. But yeah that is annoying.
Re: Friends don't let friends use inout with scope and -dip1000
On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
[...]
I need `return` for what exactly? Your code still compiles,
and my point is it shouldn't. It sure isn't memory safe.
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
int* gInt;
void f()
{
auto s=MyStruct(10);
gInt=s.ptr;
}
Error: address of variable s assigned to gInt with longer
lifetime
Looks safe to me.
With dmd 2.081.2 on Arch Linux, the code above compiles with no
error message.
Never mind, I forgot to use -dip1000. Ok, cool, so _why_ does it
work as intended now? Also, if I have to remember to annotate
correctly, surely this is a massive hole in @safe dip1000?
Re: Friends don't let friends use inout with scope and -dip1000
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
[...]
I need `return` for what exactly? Your code still compiles,
and my point is it shouldn't. It sure isn't memory safe.
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
int* gInt;
void f()
{
auto s=MyStruct(10);
gInt=s.ptr;
}
Error: address of variable s assigned to gInt with longer
lifetime
Looks safe to me.
With dmd 2.081.2 on Arch Linux, the code above compiles with no
error message.
Re: Found on proggit: Why D is a good choice for writing a language
On Tuesday, 21 August 2018 at 08:21:41 UTC, tiensonqin wrote: now it's fixed, Thank you!
Re: Found on proggit: Why D is a good choice for writing a language
On Friday, 17 August 2018 at 11:29:46 UTC, zabruk wrote: https://lambdahackers.com/@b4asile/why-d-is-a-good-choice-for-writing-a-toy-language-4vapyvas5a Can anyone explain me the purpose of javascript on this page? Especialy various mouse click event handlers, those break common well-known handfull browser behaviour? I can't select text and press mouse r-click to invoke firefox gtranslate plugin for selected text for example. Hi zabruk, sorry for the bug. I have to listen on `on-mouse-down` to let users to quote comment, now it's fixed, https://github.com/tiensonqin/lambdahackers/issues/46
