Re: New library: argparse, for parsing CLI arguments
On 2021-10-13 7:27, Andrey Zherikov wrote: Hi everyone, I'm happy to announce that I've published a CLI argument parsing library - [argparse](https://code.dlang.org/packages/argparse). It's been around for some time already so please take a look and provide your feedback if you haven't done so. The reasoning to create one more CLI parsing library is that the existing libraries do not provide enough flexibility in parsing that I'm looking for and/or they depend on other libraries. As a result `argparse` supports wide variety of data types including enums, callbacks and arrays as well as a fully customized argument parsing. It also doesn't depend on anything besides the standard library. Since it's in active development (activeness depends on my availability of course), I have few things to do before making the first major release so stay tuned and/or contribute if you'd like to. Cool! One note - gflags (https://opensource.google/projects/gflags) allows modules to define their own flags in a decentralized manner. I've always thought this is a major feature missing from std.getopt, but never got around to it. It would be great if argparse would add such support.
Re: Release D 2.094.0
On 10/1/20 5:08 PM, Meta wrote: On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila". That is correct, thanks for clarifying. Related: thanks Mathias for working on improving the status quo in function parameter modifiers. Any shake of that rusty nail is likely to improve matters.
Re: beerconf September!
On 9/12/20 4:56 PM, Steven Schveighoffer wrote: I wanted to once again give people a good notice for the next upcoming beerconf, happening September 26th and 27th. As usual, bring your favorite beverage (non alcoholic if you prefer), and bring your D topics to discuss with the crew. 3 months and running, and each one seems to be more and more fun! This time, we will try to keep a running tally of things discussed, and post back here (this was something asked about on slack, and I think it's a good idea). Will ping again before the call. Cheers! -Steve What time is it and what's the chat link?
Re: Decimal string to floating point conversion with correct half-to-even rounding
On 7/7/20 8:04 AM, Steven Schveighoffer wrote: On 7/7/20 7:13 AM, 9il wrote: On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote: On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote: On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote: There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history. Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing. It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation. That's right, it's not about the licensing. It's that the DLF should control the code it distributes. Businesses will not want to commit to a balkanized project. The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation. These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense. Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens. In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself. We have a boost license for a reason. FWIW it would be wisest to simply copy the code from Mir into druntime now with due credit. It's a minimally committal decision than can be easily revisited later. It is legal, appropriate, and there's no shame to it any more than it is for other projects to fork (parts of) dmd, druntime, or phobos.
Re: On the D Blog: Lomuto's Comeback
On 8/4/20 9:49 AM, Andrei Alexandrescu wrote:
On 8/4/20 4:19 AM, Iain Buclaw wrote:
On 04/08/2020 03:14, Andrei Alexandrescu wrote:
Interesting, thanks!
Did a quick benchmark for n in `seq 1 10` ./lomuto.exe ${n}00...
[snip]
Looks good, so committing patch. :-)
Awesome, thanks! That does solve a puzzler I had while benchmarking.
I'm thinking the story of discovering and fixing this would be a great
follow-up in the blog. It doesn't quite mesh with Mike's current
introductory series, but it could be done as an intermezzo a la "Now For
Something Completely Different (And Much Lower Level)".
Sketch of an intro:
Upon reading "Lomuto's Comeback" in the D blog, I noticed the
performance were consistently juuust a bit worse for the D version than
for the C++ version for the same source code. My own measurements
confirmed the same. That bothered me at two levels. First, people
unfamiliar with the D language would form the opinion that D cannot
reach the efficiency of C++. Second, as the gdc creator and maintainer,
I knew for a fact the produced code must be literally identical. Any
difference would pin point a bug somewhere in the code generation
pipeline. So I set out to find it and fix it. This is the story of that
investigation, which will take us through looking through disassembly,
finding the culprit, devising a fix, confirming with measurements, and
patching the open-source gdc compiler.
...
Oh, and there are a few comments to the original blog post I'd be glad
to respond to in an appendix.
Re: On the D Blog: Lomuto's Comeback
On 8/4/20 4:19 AM, Iain Buclaw wrote:
On 04/08/2020 03:14, Andrei Alexandrescu wrote:
Interesting, thanks!
Did a quick benchmark for n in `seq 1 10` ./lomuto.exe ${n}00...
[snip]
Looks good, so committing patch. :-)
Awesome, thanks! That does solve a puzzler I had while benchmarking.
I'm thinking the story of discovering and fixing this would be a great
follow-up in the blog. It doesn't quite mesh with Mike's current
introductory series, but it could be done as an intermezzo a la "Now For
Something Completely Different (And Much Lower Level)".
Sketch of an intro:
Upon reading "Lomuto's Comeback" in the D blog, I noticed the
performance were consistently juuust a bit worse for the D version than
for the C++ version for the same source code. My own measurements
confirmed the same. That bothered me at two levels. First, people
unfamiliar with the D language would form the opinion that D cannot
reach the efficiency of C++. Second, as the gdc creator and maintainer,
I knew for a fact the produced code must be literally identical. Any
difference would pin point a bug somewhere in the code generation
pipeline. So I set out to find it and fix it. This is the story of that
investigation, which will take us through looking through disassembly,
finding the culprit, devising a fix, confirming with measurements, and
patching the open-source gdc compiler.
...
Talk by Herb Sutter: Bridge to NewThingia
How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk.
Re: From the D Blog: A Pattern for Head-mutable Structures
On 6/26/20 1:02 PM, Avrina wrote: On Friday, 26 June 2020 at 13:35:20 UTC, Andrei Alexandrescu wrote: On 6/26/20 9:03 AM, Avrina wrote: On Friday, 26 June 2020 at 05:37:13 UTC, Arun Chandrasekaran wrote: On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote: I've also submitted it to HN (please use the search box): https://news.ycombinator.com/newest This is a very interesting post. But this strategy with HN is clearly not working. 5 upvotes after 17 hours and 0 comments. Please paste the direct link in future even if the ranking goes down after a few hours. Some publicity is better than nothing at all. Here. https://news.ycombinator.com/item?id=23639552 It says a lot about the priorities when you can't even get a simple link, community comes last. From https://wiredcraft.com/blog/how-to-post-on-hacker-news/: "Direct links to the post don’t allow people to vote. The link we have at the bottom of the post for example (http://news.ycombinator.com/item?id=5200847) won’t work for upvoting. We need upvotes to be made from the newest page or the front page." "It says a lot about the priorities when you can't even get a simple link, community comes last." There's some massive misunderstanding here. Do you understand the reason he did not a post a simple link?
Re: From the D Blog: A Pattern for Head-mutable Structures
On 6/26/20 9:03 AM, Avrina wrote: On Friday, 26 June 2020 at 05:37:13 UTC, Arun Chandrasekaran wrote: On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote: I've also submitted it to HN (please use the search box): https://news.ycombinator.com/newest This is a very interesting post. But this strategy with HN is clearly not working. 5 upvotes after 17 hours and 0 comments. Please paste the direct link in future even if the ranking goes down after a few hours. Some publicity is better than nothing at all. Here. https://news.ycombinator.com/item?id=23639552 It says a lot about the priorities when you can't even get a simple link, community comes last. From https://wiredcraft.com/blog/how-to-post-on-hacker-news/: "Direct links to the post don’t allow people to vote. The link we have at the bottom of the post for example (http://news.ycombinator.com/item?id=5200847) won’t work for upvoting. We need upvotes to be made from the newest page or the front page."
Re: Beta 2.093.0
On 6/24/20 5:01 PM, Martin Nowak wrote: Glad to announce the first beta for the 2.093.0 release, ♥ to the 53 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.093.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thanks! Would be great to build dmd with ldc for the distributed binaries.
Re: News on the D Blog: SAOC 2020 and More
On 6/23/20 10:31 AM, Meta wrote: On Tuesday, 23 June 2020 at 13:45:56 UTC, user1234 wrote: On Tuesday, 23 June 2020 at 12:00:30 UTC, Mike Parker wrote: On Tuesday, 23 June 2020 at 12:00:06 UTC, Mike Parker wrote: Symmetry Autumn of Code 2020 is on! My latest news post on the D Blog talks about that, some D Language Foundation finance updates, and whispers on the wind. And you can read all about it here: https://dlang.org/blog/2020/06/23/saoc-2020-and-other-news/ "Thanks are also in order to those who have supported the foundation through smile.amazon.com. Your purchases have brought over $288" That is interesting, that means that dlang users spent ~57,600.0 bucks on Amazon recently. And that's probably only a minority as people don't necessarily remembers that smile.amazon thing. I guarantee I spent at least $1000 on Amazon in 2019, and I've ordered a lot of stuff off there that I wouldn't normally, given the quarantine. I don't usually buy from amazon.com as I'm not in the US, but I did set mine to donate to the DLF when I do. By the way I found this helpful: https://chrome.google.com/webstore/detail/smile-always/jgpmhnmjbhgkhpbgelalfpplebgfjmbf?hl=en
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On 6/17/20 7:19 AM, Atila Neves wrote: On Wednesday, 17 June 2020 at 10:43:35 UTC, Stanislav Blinov wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism. I've got to ask though. Why "tardy"? Search engines be damned? :) Late binding ;) Love the name.
Re: Interesting work on packing tuple layout
On 6/14/20 3:36 PM, Timon Gehr wrote: On 14.06.20 20:25, Paul Backus wrote: On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote: The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic. Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order. Indeed, that's why I noted that the obvious way to achieve that does not work. Although some assumptions will break, for example, there might be code that assumes that tupleof does the same thing as expand. I was thinking about e.g., manual cache optimization, but reducing size in the common case where such considerations are not made may well be more important. If it can be done at all; I am not currently aware of a workaround. It's really easy if members in the layout are given internal names that include information about the original index.
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 6/14/20 4:22 PM, Timon Gehr wrote: On 04.06.20 14:46, Andrei Alexandrescu wrote: PLDI (Programming Language Design and Implementation) is a top academic conference. This year PLDI will be held online and registration is free. This is an amazing treat. https://conf.researchr.org/home/pldi-2020 Workshops and tutorials (also free) are of potential interest. These caught my eye: https://pldi20.sigplan.org/home/SOAP-2020 (on the 15th) https://conf.researchr.org/track/ismm-2020/ismm-2020 (on the 16th) For PLDI 2020, I have contributed to the following research papers: https://pldi20.sigplan.org/details/pldi-2020-papers/47/Silq-A-High-Level-Quantum-Language-with-Safe-Uncomputation-and-Intuitive-Semantics https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs The only relation to D is that the implementations of the two presented programming languages are written in D. Congratulations! Mmmm, safe :o)
Re: Interesting work on packing tuple layout
On 6/14/20 12:26 PM, Avrina wrote: On Sunday, 14 June 2020 at 03:57:40 UTC, Andrei Alexandrescu wrote: On 6/13/20 11:55 PM, Avrina wrote: On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote: On 6/13/20 7:30 PM, Timon Gehr wrote: Another question is if automatic packing is worth making the layout harder to predict. I think so. Size does matter. If you are talking about implementing a tuple type into the language, negative The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic. No. There's no guarantee made by std.tuple as to layout. We can't be overly conservative for the sake of supporting code that assumes too much.
Re: Interesting work on packing tuple layout
On 6/14/20 2:25 PM, Paul Backus wrote: On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote: The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic. Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order. Indeed.
Re: Interesting work on packing tuple layout
On 6/13/20 11:55 PM, Avrina wrote: On Sunday, 14 June 2020 at 03:08:48 UTC, Andrei Alexandrescu wrote: On 6/13/20 7:30 PM, Timon Gehr wrote: Another question is if automatic packing is worth making the layout harder to predict. I think so. Size does matter. If you are talking about implementing a tuple type into the language, negative
Re: Interesting work on packing tuple layout
On 6/13/20 7:30 PM, Timon Gehr wrote: Another question is if automatic packing is worth making the layout harder to predict. I think so. Size does matter.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On 6/13/20 2:39 PM, Paul Backus wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Cool stuff! What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object? FWIW that could be avoided with extern(C++) classes.
Interesting work on packing tuple layout
https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple Would be interesting to adapt it for std.tuple.
This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
PLDI (Programming Language Design and Implementation) is a top academic conference. This year PLDI will be held online and registration is free. This is an amazing treat. https://conf.researchr.org/home/pldi-2020 Workshops and tutorials (also free) are of potential interest. These caught my eye: https://pldi20.sigplan.org/home/SOAP-2020 (on the 15th) https://conf.researchr.org/track/ismm-2020/ismm-2020 (on the 16th)
Alpine Linux 3.12 Released With D Language Support
https://www.phoronix.com/scan.php?page=news_item=Alpine-Linux-3.12-Released
Re: DIP 1028 "Make @safe the Default" is dead
On 5/30/20 7:39 AM, Nick Treleaven wrote:
On Friday, 29 May 2020 at 21:18:13 UTC, Walter Bright wrote:
On 5/29/2020 2:07 AM, Timon Gehr wrote:
It would be great if `@safe:` did not affect declarations that would
otherwise infer annotations.
The idea is the simple, general rule that:
attribute declaration;
attribute { declaration; }
attribute: declaration;
behave the same way.
To preserve this, then please can we have `@safe module foo;`.
We already have that in Yoda notation:
module foo; @safe:
Re: DIP 1028 "Make @safe the Default" is dead
On 5/29/20 12:53 AM, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Thank you. Unrelated to this decision, I wanted to apologize for having lowered the quality of discourse in this forum.
Re: DIP1028 - Rationale for accepting as is
On 5/27/20 9:42 AM, Andrej Mitrovic wrote:
On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
Un-annotated C declarations should be a red flag to any competent QA
team. Recognizing a false @trusted is a whole lot harder.
Is the actual problem those `@trusted:` declarations at the top of C
headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to multiple symbols. Only
allow `@trusted` to apply to a single symbol. For example:
Oh wow what an interesting idea. Thanks.
Re: DIP1028 - Rationale for accepting as is
On 5/27/20 6:22 AM, Walter Bright wrote: On 5/27/2020 3:06 AM, rikki cattermole wrote: Open to everybody and it can be recorded by Twitch. I've done the video conferencing many times over the decades. I just don't find it to be productive. Maybe it's some defect in me. They usually go something like this: [attempt at joke snipped] It's safe to assume things have improved over time.
Re: DIP1028 - Rationale for accepting as is
On 5/27/20 6:03 AM, Walter Bright wrote: On 5/26/2020 5:20 AM, Johannes T wrote: On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote: [..] Thank you very much for your patience with all the negative feedback. I get your decision to not annotate extern C with @system by default. The biggest issue with extern @system is that @trusted would become less useful when dealing with declarations and bindings. @trusted would appear more frequently. We wouldn't be able to assume that the author put in effort in assessing the trustworthiness of a declaration. More greenwashing, less safety. Those are severe drawbacks, I agree. However, as Andrei pointed out, PR is a huge problem. We need to be able to sell it with a straight face. Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish. Didn't work with me.
Re: Rationale for accepting DIP 1028 as is
On 5/27/20 1:49 AM, Walter Bright wrote: On 5/26/2020 9:31 AM, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? Nothing at all. That means safe by default is effectively loosening D's notion of safety. This DIP must go.
Re: Rationale for accepting DIP 1028 as is
On 5/26/20 12:31 PM, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? If that's the case, it's the death of DIP 1028.
Re: DIP1028 - Rationale for accepting as is
The DIP is trying to accomplish (copied from its Rationale): A. Costs of unsafe code have become ever more apparent and expensive, and @safe has grown more capable. Users expect safety to be opt-out, not opt-in. B. Most code should be naturally safe, and system code should be relatively rare. It makes sense that the common case - safe code - should be the default and not require an annotation. Any judgment on the regime of extern(C) functions should be judged as follows: "To what extent does the chosen regime of C functions push the rationale forward?" The decision fails to support (A) because it keeps safety of C functions opt-in. It also fails to support (B) because it keeps code that does not require an annotation yet is not safe. A good process would simply go back to the drawing board once the matter is exposed. It is very easy for reasonable people to agree that there is no part of rationale that justifies the decision. Either redefine the rationale (adding e.g. "keep some applications compilable without change" as an important goal), or change the handing of C functions. The core argument recently detailed is: A. Define "greenwashing" as a quick workaround to get code to work. B. Describe in excruciating detail the experience with Java exceptions. C. Establish a vague analogy with people placing @trusted on C declarations. D. Assume without stating that the user would do "greenwashing" but the compiler doing it surreptitiously is somehow exempt. E. Conclude that extern(C) code must be trusted. This argument is already a smorgasbord of fallacies. It iterates a good subset of https://en.wikipedia.org/wiki/List_of_fallacies, and I am not kidding when I say a few edits to those pages with backreferences to this thread would be appropriate. To start: False analogy: making extern(C) function system is analogous with the Java exeception specification debacle. https://en.wikipedia.org/wiki/Argument_from_analogy#False_analogy This is a false analogy belying what seems to be a misunderstanding of the problem with Java exceptions: it was a maintenance problem, not an introduction problem. The matter was, during maintenance, routinely code would change the set of exceptions they threw. So maintainers would need to touch code that didn't belong to them. There was also no "shrinking" of exception specification lists because the compiler does not enforce larger-than-necessary lists. So these lists would just grow forever during maintenance, with no real information attached and no usefulness. None of these apply to @safe. Functions don't change their safety with ease, and when they do you definitely want to be informed. There's no growth of attributes for obvious reasons. To the extent the analogy applies, the burden of proof is entirely on the DIP, and in this case the differences are so many and large, it's not worth making the argument by analogy in the first place. The excruciatingly long discussion of Java exception specifications is an instance of another fallacy, misleading vividness: http://nizkor.com/features/fallacies/misleading-vividness.html It was expected that any of the bad things about exceptions would count as yet another good argument for the DIP. This constructs a textbook straw man: https://en.wikipedia.org/wiki/Straw_man So the argument constructs a straw man (Java exception specifications), discusses it at length on a long tangent (misleading vividness), to then conclude (by false analogy) that we don't want extern(C) functions to be @system. What's missing is, of course, an explanation on how the decision supports the very rationale of the DIP. Which it doesn't - it factually works straight against it. I decided to make this public only once the second boot fell (read on): On 5/23/20 11:28 PM, Walter Bright wrote: I'd like to emphasize: 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe. Strawman: https://en.wikipedia.org/wiki/Straw_man Nobody asked for that, and listing it as an argument is pointing at a strawman. 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. Nirvana fallacy: https://en.wikipedia.org/wiki/Nirvana_fallacy "Electric cars still use polluting materials and processes, so let's continue making gasoline cars." "People will add workarounds to code, so let's accept the dangerous code anyway." 3. Un-annotated declarations are easily detectable in a code review. Proof by assertion: https://en.wikipedia.org/wiki/Proof_by_assertion (Um... there's no grep for "find me all un-annnotated declarations") 4. Greenwashing is not easily detectable
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/23/20 6:49 PM, ag0aep6g wrote: On 23.05.20 17:07, Andrei Alexandrescu wrote: A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. I can only read that as you calling larsivi not "good enough to lead a successful fork" and not "wise enough to work on the D language instead". Walter says: "Belittling [others] [...] is unprofessional behavior." He was refering to other people on the forum, of course. But I would expand that to authors of other projects as well, particularly ones that are (even) smaller than D. Punching down is not cool. The point is on the other side - the barrier is very high. Carrying a programming language design and implementation is an extremely difficult task.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 5/21/20 7:49 PM, Bruce Carneal wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time? A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead. A committee would work if the community were at least one order of magnitude larger. It's just big numbers. Walter is world-class, another way of saying there's only a few of comparable strength in the world. A larger community would mean a larger likelihood of there being other people of comparable strength in it. Those could form a committee. As things are, Walter is so much stronger than every one of us, the relationship is highly asymmetric. His strength comes with equally unique ability to explain and debate, which makes many of the discussions in forums very frustrating.
Re: On the D Blog: Lomuto's Comeback
On 5/14/20 9:26 AM, Mike Parker wrote: After reading a paper that grabbed his curiosity and wouldn't let go, Andrei set out to determine if Lomuto partitioning should still be considered inferior to Hoare for quicksort on modern hardware. This blog post details his results. Blog: https://dlang.org/blog/2020/05/14/lomutos-comeback/ Reddit: https://www.reddit.com/r/programming/comments/gjm6yp/lomutos_comeback_quicksort_partitioning/ HN: https://news.ycombinator.com/item?id=23179160 Looks like the blog post is enjoying a second wind after being posted by soneone else on hackernews. It's in top 10 right now.
Re: On the D Blog: Lomuto's Comeback
On 5/14/20 11:57 AM, jmh530 wrote: On Thursday, 14 May 2020 at 13:40:24 UTC, Andrei Alexandrescu wrote: [snip] Really interesting. Thanks for sharing. I have recently been spending some spare time learning more about D's topN and pivotPartition implementation, which led me to your paper on fast deterministic selection. Would you consider changing the pivotPartition implementation based on this? Yes, and I encourage you to look into putting together a PR. Would the insights gleamed from this paper mean that a branchless version of topN could be faster? Yes. topN also uses partitioning.
Re: On the D Blog: Lomuto's Comeback
On 5/14/20 9:26 AM, Mike Parker wrote: After reading a paper that grabbed his curiosity and wouldn't let go, Andrei set out to determine if Lomuto partitioning should still be considered inferior to Hoare for quicksort on modern hardware. This blog post details his results. Blog: https://dlang.org/blog/2020/05/14/lomutos-comeback/ Reddit: https://www.reddit.com/r/programming/comments/gjm6yp/lomutos_comeback_quicksort_partitioning/ HN: https://news.ycombinator.com/item?id=23179160 Thanks, Mike. HN has possibly categorized it as spam already. One thing they do is they detect (by using the "Referrer" header) whether the post has been shared via a direct link. They do so to prevent manipulation. The right way to share something on hackernews is to send people to https://news.ycombinator.com/newest and mention the time of sharing.
Our HOPL IV submission has been accepted!
Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve.
Re: Blog Post: Beating std::visit Without Really Trying
On 10/6/19 3:09 AM, Joseph Rushton Wakeling wrote: You misunderstand what I mean by "battle-testing". Clearly designs should go through a high level of testing and usage before they go anywhere near the standard library. But the very fact of being placed in the standard library exposes them to orders of magnitude more usage, and hence gives a much stronger guarantee of establishing their correctness (or identifying their flaws). Well also in the case of SumType there's not even much battle-testing. It's more of an implementation than a design. Take the existing variant, keep the interface, remove the cruft, put in the new nice code. Make it pass the unittests, and release. Of course it's an involved process, but definitely not more difficult than writing the new code to start with. The author receives credit as the primary author of the facility. It is wonderful service to the community - not only offers better speed for new code, but it instantly enhances speed of existing variant uses.
Re: Blog Post: Beating std::visit Without Really Trying
On 10/5/19 7:58 AM, Seb wrote: On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran wrote: On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote: I was curious how C++17's std::variant compared to the options we have in D, like Algebraic and SumType, so I did a simple comparison of the generated assembly for each of them. You can read about it at the link below. And as you can probably guess from the title, D comes out ahead, in the end. https://pbackus.github.io/blog/beating-stdvisit-without-really-trying.html This is my first attempt at sharing something like this, so any comment or feedback is very much appreciated! Good one. Any plans to push SumType as a replacement of Phobo's Algebraic? Phobos is essentially dead/frozen (feature-wise). Though if someone ever manages to get v2 of the ground, SumType would be the obvious choice. I think we'd do good to choose words with care. An extraordinary assertion, however odd and unjustified, may go by chance unchallenged and if repeated enough soon starts passing as the accepted truth. This is very damaging, regardless of how well it was intended initially, goodwill I have no doubt about. To set the record straight: Phobos is not dead and is not frozen feature-wise. It is and has always been open to adding new functionality, and of course to improve implementation of existing functionality. Variant's design and implementation are very, very, very old. We're talking 15 years. It is literally the first generic design I've ever done in D, and at the time getting it (or anything nontrivial) to work was a large challenge. At that time only the most basic examples worked for any template-related feature. The code also predates most of the CTFE niceties we now take for granted, static foreach included. Not to mention, I'd be the first to say I engineered the thing poorly. A radical simplification is definitely possible and desirable. Anyhow, currently we would have to name it differently (e.g. dts - https://github.com/wilzbach/dts). Maybe the upcoming SAoC project will change this and allow multiple versions of a library to co-exist in a binary. Adding it as a new facility is a possibility, but only if the challenges of keeping the existing interface are too large.
Re: bool (was DConf 2019 AGM Livestream)
On 5/14/19 2:00 AM, Mike Franklin wrote: On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote: There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones. Once again, I disagree with what you think is important. `bool` is a fundamental type on which many things in D depend. I'd be hard pressed to find my style cramped by D's bool. If it doesn't work right, neither will the features that depend on it. But, that's your decision, and there's little to nothing we can do about it, so I guess we just accept the fact that D is clowny and deal with it; it's what so many of us, so often do. (At any rate, going forward it's not me who needs convincing.) In my humble opinion, any language would have minor quirks, and a landmark of good engineering is attacking the right problems. That we even discuss just how bad bool is while we have no done deals for safety, reference counting, shared, package distribution/versioning, pay-as-you-go runtime, collections, ..., is a fascinating puzzle.
Re: bool (was DConf 2019 AGM Livestream)
On 5/14/19 8:47 PM, Mike Franklin wrote: On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote: On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote: All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers* FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool? At the time the DIP was written, we didn't know Walter conflates bool and bit. Now that we do a new DIP could argue differently that bool and bit should not be conflated and that that would also fix the overload issues. There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones.
Re: bool (was DConf 2019 AGM Livestream)
On 5/12/19 11:46 PM, H. S. Teoh wrote: On Sun, May 12, 2019 at 01:20:16PM +, Mike Franklin via Digitalmars-d-announce wrote: [...] If anyone's looking for a challenge, I welcome them to propose a new `Bool` type (note the capital B) for inclusion in my new library. [...] As long as && and || continue to evaluate to a 1-bit integer, all library efforts to implement Bool will be futile. When writing std.typecons.Ternary I thought of overloading opBinary for | and & to take a lazy argument on the right. I forgot why I ended up not doing it (I think it was because of code generation issues). This is something that could be made to work.
Re: bool (was DConf 2019 AGM Livestream)
On 5/12/19 1:34 PM, Nicholas Wilson wrote: However in this case the community consensus is that the chain of reasoning you have used to arrive at your decision is wrong. It's a simple enough matter to be understood, and reasonable to assume Walter is not missing any important facts or details. Poking holes in his explanations is, I confess, attractive, but ultimately are about debate skills rather than technical. I do agree that the way explanations on DIP decisions go could and should be improved a lot.
Re: bool (was DConf 2019 AGM Livestream)
On 5/12/19 11:27 AM, Isaac S. wrote: This is the crux of the argument: *How* does making bool an integer add to the language? The crux of the argument is there was a D Improvement Proposal on a small language change, and it was rejected. Rejected D Improvement Proposals on small matters that D language's leader thinks strongly about should allow everybody to move on to larger, better things. We are unable to, and should not be required to, provide argumentation when making a decision on a DIP that will be to the satisfaction of everybody involved. Of course, pressure does exist on making the right decision and on framing it properly; otherwise, one poor decision after another, we end up with a bad language that people will not want to use. Walter's last argument in this thread is poorly made and has several factual errors. He's traveling and with a bunch of stuff going on right after DConf. But the larger point is it doesn't matter - the DIP was looked at and rejected (I should add I concurred with the decision and still do). Bringing it up over and over again, like a perennial fight in a marriage, with the hope of finally convincing the spouse on the wrongness of their views - that all is wasted time. There's a bunch of big rocks to move.
DConf 2019 Day 2 Livestream
Just checked, it works: https://youtu.be/Vj6jNAlv03o
grain - D Language for Deep Learning
Google Alerts just found these slides: https://speakerdeck.com/shigekikarita/grain-d-language-for-deep-learning Does anyone have more information about this?
Re: DIP 1018--The Copy Constructor--Formal Review
On 02/25/2019 03:41 PM, Paolo Invernizzi wrote:
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:
On 2/25/19 3:23 PM, Jacob Carlborg wrote:
On 2019-02-25 20:24, Mike Parker wrote:
From the process document:
“the DIP Manager or the Language Maintainers may allow for
exceptions which waive requirements or responsibilities at their
discretion.”
Having it documented doesn't make it less flawed.
Jacob, are there amends you need to make to the DIP?
Honestly, I've not understood the rationale or the covered use case in
letting the copy ctor mutate the ref source parameters...
Sincerely, without polemical intent.
I made an editorial pass:
https://github.com/dlang/DIPs/pull/145
The most material change was additional explanation of using mutable ref
instead of e.g. const. Here's the relevant excerpt, please let me know
if it clarifies the motivation.
=
1. The parameter of the copy constructor is passed by a mutable
reference to the
source object. This means that a call to the copy constructor may
legally modify
the source object:
```d
struct A
{
int[] a;
this(ref A another)
{
another.a[2] = 3;
}
}
void main()
{
A a, b;
a = b;// b.a[2] is modified
}
```
This is surprising and potentially error-prone behavior because changing
the source of a copy is not customary and may surprise the user of a
type. (For that reason, C++ coding standards adopt the convention of
taking the source by means of reference to `const`; copy constructors
that use non-`const` right-hand side are allowed but discouraged.) In D,
`const` and `immutable` are more restrictive than in C++, so forcing
`const` on the copy constructor's right-hand side would make simple
copying task unduly difficult. Consider:
```d
class Window
{
...
}
struct Widget
{
private Window display;
...
this(ref const Widget rhs)
{
display = rhs.display; // Error! Cannot initialize a Window
from a const(Window)
}
}
```
Such sharing of resources across objects is a common occurrence, which
would be impeded by forcing `const` on the right-hand side of a copy.
(An inferior workaround would be to selectively cast `const` away inside
the copy constructor, which is obviously undesirable.) For that reason
this DIP proposes allowing mutable copy sources.
=
Re: The D Programming Language has been accepted as a GSoC 2019 organization
On 2/26/19 5:34 PM, Seb wrote: Hi all, I have some very exciting news to share. The D Language Language got accepted as a Google Summer of Code organization! A few of us were waiting for permission to announce all day :o). Congratulations to Mike, Seb, and all others who made our proposal successful. Let's get in gear for a great summer. It's time for ideas!
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 9:26 PM, Manu wrote: On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via Digitalmars-d-announce wrote: On 2/25/19 2:41 PM, bachmeier wrote: On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” If you were to write a DIP for a feature they think important enough, it could be fast tracked, too. I hate to be so negative, but when I see D's corporate management structure, the lack of community contribution is obvious. It doesn't exactly motivate contributions. This is no way to run an open source project. I understand that it works well for Facebook because everyone on the team is paid six figures, and they can be replaced in two hours, but an open source project is not Facebook. I know the whole argument about why it is that way. That doesn't mean it's going to work. What do you recommend? Should we carry a final review here? In my case, you could have produced useful and not-completely-wrong rejection text with the rejection, and then not insulted me a few times before eventually producing some actionable feedback. I mean, its in your interest to foster contribution, not repel it. I apologize again for my use of unkind words. If there's something else I can do to atone, please let me know.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 7:23 PM, Nicholas Wilson wrote: There are similarities and differences between our DIP process and paper submission reviews at conferences and journals everywhere; one key similarity is that the submitters are on hook for providing convincing submissions, whereas reviewers are not required to defend their reviews. It's an asymmetric relationship that occasionally frustrates, but it is as such for good reason and it works. I've said before that that comparison is weak and not particularly useful, irrespective of its intention. That you've said it before does not make it any more correct. We have intently modeled the acceptance process after that used by the review process used by conferences, journals, and standardization committees - naturally from the communities I have some familiarity with (Programming Languages, Machine Learning, Natural Language Processing, Algorithms, ISO C++). So the alleged similarities are more of a statement of fact than a metaphor. There are differences, too, of which the public discussions in this forum is the main one. This is in danger of getting abused; open discussions around DIPs in this forum give the false impression that DIP authors have the authority to demand any extent of explanation and justification of a decision. We do not have the capacity to do that, and it would not be anymore appropriate than journal reviewers being required to provide detailed feedback to submitters' satisfaction. This whole notion of a meeting whereby Walter is grilled by a committee on why exactly he rejected DIP 1016 is Kafkaesque. The keyword here is "short". By suggesting that the action required is to rewrite, the order is most definitely not short. Time is a valuable resource, and a new DIP from scratch through the DIP process takes a lot of it. You can count on me to massage the bureaucracy out of the process if that's the bottleneck. The most significant bit is to focus on working together toward making the proposal better, as opposed to focusing on negotiating acceptance. But whether the DIP keeps the number or gets another one, if the revised document is a 95% cut and paste of the existing one, the review is liable to be a 95% cut and paste of the existing one.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 6:09 PM, Olivier FAURE wrote: Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes sense that it was fast-tracked, because it fits a priority of the project owners (C++ interoperability + reference counting) and project owners are allowed to have priorities. It's not like this DIP was rushed or has major vulnerabilities (the "mutable copy constructor" thing is necessary for reference counting). I haven't heard the final decision from Walter yet, but I proposed that in the interest of quality, we will go through the customary two weeks reviews with DIP 1018.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 3:41 PM, Paolo Invernizzi wrote: On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote: On 2/25/19 3:23 PM, Jacob Carlborg wrote: On 2019-02-25 20:24, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” Having it documented doesn't make it less flawed. Jacob, are there amends you need to make to the DIP? Honestly, I've not understood the rationale or the covered use case in letting the copy ctor mutate the ref source parameters... Sincerely, without polemical intent. We'll look into clarifying that better, thanks.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 3:23 PM, Jacob Carlborg wrote: On 2019-02-25 20:24, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” Having it documented doesn't make it less flawed. Jacob, are there amends you need to make to the DIP?
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 2:41 PM, bachmeier wrote: On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” If you were to write a DIP for a feature they think important enough, it could be fast tracked, too. I hate to be so negative, but when I see D's corporate management structure, the lack of community contribution is obvious. It doesn't exactly motivate contributions. This is no way to run an open source project. I understand that it works well for Facebook because everyone on the team is paid six figures, and they can be replaced in two hours, but an open source project is not Facebook. I know the whole argument about why it is that way. That doesn't mean it's going to work. What do you recommend? Should we carry a final review here?
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 2:24 PM, Mike Parker wrote: On Monday, 25 February 2019 at 18:51:17 UTC, Jacob Carlborg wrote: On 2019-02-24 11:46, Mike Parker wrote: Walter and Andrei have requested the Final Review round be dropped for DIP 1018, "The Copy Constructor", and have given it their formal approval. They consider copy constructors a critical feature for the language. Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance. I think the process is flawed when not everyone plays by the same rules. From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” If you were to write a DIP for a feature they think important enough, it could be fast tracked, too. Thanks, Mike. We were a bit surprised ourselves by the scarce response during the community review stage. That said, Jacob and others, if there is a case for the final review please let us know.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 1:39 PM, Jacob Carlborg wrote: On 2019-02-25 17:31, Andrei Alexandrescu wrote: The proposers (Razvan and myself) and Walter (the reviewer) do not know how to make DIP 1018 better. That shouldn't justify accepting a DIP that might contain problems. Definitely. But of course, if you don't think there are any problems. Not talking for Walter, but generally acceptance implies that.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/24/19 4:02 PM, Manu wrote: On Sun, Feb 24, 2019 at 2:50 AM Mike Parker via Digitalmars-d-announce wrote: Walter and Andrei have requested the Final Review round be dropped for DIP 1018, "The Copy Constructor", and have given it their formal approval. They consider copy constructors a critical feature for the language. Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance. The DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md The implementation: https://github.com/dlang/dmd/pull/8688 I mean like, my DIP was almost violently rejected, but in here there's text like this: "The parameter of the copy constructor is passed by a mutable reference to the source object. This means that a call to the copy constructor may legally modify the source object:" I can't see how that could be seen in any way other than what might reasonably be described as "a hole large enough to drive a truck through"... Thanks for the observation. We do not think this creates a hole in the language. Indeed there is risk for misuse but we thought it's better to pass the "true" source of the copy to the constructor instead of affixing additional qualifiers to it. There are important simplicity benefits to doing so because "const" is ambiguous in D as it could originate either from mutable or immutable data. Furthermore, the risk is encapsulated in the type's implementation and not as a misunderstanding between the caller and the callee. I'll add that pointing out a DIP's weaknesses in order to claim an injustice in another DIP is a understandable, but not productive. The proposers (Razvan and myself) and Walter (the reviewer) do not know how to make DIP 1018 better. Walter and I do know, and we have shared, how to make DIP 1016 better. Andrei
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 10:45 AM, Atila Neves wrote: The *only* problem I have with const in D is that const values can't be copied, which is silly. I'd expect DIP1018 to fix that. Affirmative. It was tricky.
Re: DIP 1018--The Copy Constructor--Formal Review
On 2/25/19 1:06 AM, Nicholas Wilson wrote: On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote: Your DIP, and nobody else is going to do it, so it falls to me. It will be reviewed at Dconf, please make sure you have an _accurate_ summary of your criticisms of the DIP ready for then. This seems to be a misunderstanding of protocol. A negative review is simply a signal that the submission has not been strong enough. As such, the submission, not the review, needs to be improved. There are similarities and differences between our DIP process and paper submission reviews at conferences and journals everywhere; one key similarity is that the submitters are on hook for providing convincing submissions, whereas reviewers are not required to defend their reviews. It's an asymmetric relationship that occasionally frustrates, but it is as such for good reason and it works. It does happen in such processes that a submission is rejected wrongly, by means of reviews that do not reflect the quality of the submission. This is the case most often when a nonspecialist reviews a specialty paper and fails to appreciate the subtler aspects of the submission. In this DIP's case, we submit this is not the case here; to the extent the DIP failed to convey its intent, that is squarely a pervasive matter with the DIP itself. It is not a matter of misunderstanding 1-2 sentences, but a problem of precision in specification that needs to be approached with due care. Thorough feedback has been given, likely more so than for any other submission. A summary for the recommended steps to take can be found here: https://forum.dlang.org/post/q2u429$1cmg$1...@digitalmars.com It is not desirable to demand reviewers to do more work on the review or to defend it. Acceptance by bullying is unlikely to create good results. The target of work is squarely the proposal itself. Our understanding after Manu asked for action items was that he would be up for the work in short order. Not wanting to step on any toes and seem like taking away credit, Walter decided to hold off on working on it although he wanted to do so now that the matter is in his hands. Now that after three weeks Manu gave permission, I assume Walter would be up for the task. Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 4:42 PM, Olivier FAURE wrote: On Thursday, 31 January 2019 at 16:38:42 UTC, Steven Schveighoffer wrote: Yeah, that's already a thing that ref in D doesn't protect against: It took me a while to understand what the compiler was doing. This really feels like something that shouldn't compile. The proposal could actually disallow rvalues that have lvalue syntax, such as "symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets hairy quickly.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/31/19 11:38 AM, Steven Schveighoffer wrote:
On 1/31/19 11:04 AM, Olivier FAURE wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
I still can't see a truck-sized hole.
I don't know if it's truck-sized, but here's another corner case:
int doubleMyValue(ref int x) {
x *= 2;
return x;
}
Point pt;
pt.x = 5;
pt.y = foobar();
doubleMyValue(pt.x);
assert(pt.x == 10);
Question: in the above code, will the assertion pass?
Answer: it depends on Point's implementation. If x is a member
variable, then yes. If it's a getter, then doubleMyValue will take a
rvalue and x won't be mutated and the assertion will fail.
I think this is a non-trivial conceptual problem.
Yeah, that's already a thing that ref in D doesn't protect against:
struct Point
{
private int _x, _y;
ref int x() { return _x; }
ref int y() { return _y; }
}
struct Rect
{
private Point _origin, _lengths;
Point origin() { return _origin; }
Point lengths() { return _lengths; }
void origin(Point p) { _origin = p; }
void lengths(Point p) { _lengths = p; }
}
Rect r;
r.origin = Point(1, 2);
r.lengths = Point(5, 5);
doubleMyValue(r.lengths.x);
assert(r.lengths.x == 10); // fail
-Steve
Affirmative. This discussion should be part of the revised DIP along
with an assessment of its gravity.
Goes the same with scope-level variables replaced with homonym functions
that return rvalues.
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 10:12 PM, Manu wrote:
On Wed, Jan 30, 2019 at 7:05 PM Nicholas Wilson via
Digitalmars-d-announce wrote:
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote:
On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via
fun(my_short); // implicit type conversions (ie, short->int
promotion)
Oh I see.
fun(short(10)); // implicit type conversions (ie, short->int
promotion)
I did not intend for this DIP to apply to anything other than
rvalues.
I can totally see how that's not clear. `my_short` should be an
rvalue
of some form, like the rest.
Is that the only such line?
I think so.
Presumably my_short is a variable of type short. Is that
correct?
It is not. It should be an rvalue like everything else. Perhaps
it's an enum... but I should write `short(10)`, that would be
clear.
It would.
* DIP 1016 proposes a hole in the language one could drive a
truck through.
I still can't see a truck-sized hole.
* The problem goes undetected in community review.
I don't know how I could have influenced this outcome.
* Its own author seems to not have an understanding of what
the DIP proposes.
More classy comments. I can't get enough of the way you
belittle people.
I made a 1-word error, where I should have written `short(10)`
to be clear.
1-word error feels amendment-worthy, and not a call for "let's
start
over from scratch".
You should just PR it back to review
I can't do that, it's been rejected, with mostly incorrect rejection
text affixed to the bottom.
with that fix and a note
about how it lowers to statements (incl. an example of
lambdification for if/while/for/switch statements (see
https://forum.dlang.org/post/qysmnatmjquuhylaq...@forum.dlang.org
))
I'm pretty sure that's not necessary. I haven't understood why this
noise about expressions. This DIP applies to statements.
I can't see how there's any problem with the lowering if the statement
is a control statement?
if (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
if (ref_fun(__tmp)) { ... }
}
What's the trouble?
The trouble is major.
Replace "if" with "while":
while (ref_fun(10)) { ... }
==>
{
int __tmp = 10;
while (ref_fun(__tmp)) { ... }
}
That means ref_fun is called with the same lvalue multiple times. In all
likelihood this is not what you want!
A possible retort is: "Of course, while would not be lowered that way,
but a slightly different way!" etc. The point is, ALL OF THAT must be in
the DIP, not assumed obvious or clarified in informal discusson outside
the DIP.
Again: please be thorough, state your assumptions, cover all cases.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 10:05 PM, Manu wrote: On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via Digitalmars-d-announce wrote: On Wednesday, 30 January 2019 at 18:29:37 UTC, Manu wrote: On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via Digitalmars-d-announce wrote: The result of a CastExpression is an rvalue. An implicit cast is a compiler-inserted CastExpression. Therefore all lvalues with a potential implicit cast are rvalues. But there's no existing language rule that attempts to perform an implicit cast where an lvalue is supplied to a ref arg...? Why is the cast being attempted? 'p' is an lvalue, and whatever that does should remain exactly as is (ie, emits a compile error). We could perhaps allow this for `const` args, but that feels like separate follow-up work to me, and substantially lesser value. This DIP doesn't want to change anything about lvalues. It appears to say it does: fun(my_short); // implicit type conversions (ie, short->int promotion) You should clarify that ;) Yes, as said above, read `short(10)`. I can understand the confusion that it may look like a variable when taken out of context; but listed beneath the heading immediately above which says: "This inconvenience extends broadly to every manner of **rvalue** passed to functions" It didn't occur to me the reader might interpret the clearly stated list of cases of rvalues passed to functions to include arguments that are not rvalues. The name was just chosen to indicate the argument is a short, perhaps an enum, or any expression that is a short... I could have used `short(10)`, but apparently I didn't think of it at the time. Is this the basis for the claims of "a hole you could drive a truck through"? Affirmative. With the restriction that the expression passed into the function must be an rvalue to start with, by Walter's and my understanding, the proposed semantics would work and be helpful. Again, a request for clarification, and a couldn't-possibly-be-more-trivial revision may resolve this. Negative. It must be clear that the reason of this misunderstanding is squarely due to the DIP itself. It has multiple problems of informality and vague language that have worked together to cause said misunderstanding. (It is great it's just that, a misunderstanding; I have been worried people would believe such an awful semantics was considered just fine. That explains but does not justify my use of unkind language.) The DIP must convince the reader, and in a way the reader does not "owe" the DIP. For good reason, they call the research theme chosen by a doctoral candidate a "charge"; the root of "dissertation" is Latin for "debate"; and the final doctoral examination is plainly called a "defense". The whole thing is structured like a criminal investigation :o). Of course we don't want to be as harsh as academics could get, but we don't want to transform DIP acceptance into a farmers market bargaining process. So the code with my_short was open to interpretation. Cool. In a thorough submission, however, there would have been many places that clear that up: * Use of a distinct notation (non-code non-text font for metalanguage, i.e. general expressions); * Description of the typechecking process, with examples of code that passes and code that fails; * A clarification that lowering proceeds not against all expressions, but only against rvalues; * Several places in text in which it is explained that rvalues resulted from implicit conversions are not eligible; * etc. etc. etc. So if we rejected the DIP, we didn't do so on account of one word that can be so easily changed; we did so on account of a DIP that as a whole failed to clarify what it purports to do (and equally importantly, to not do). The purpose of us all is to move things forward, and in that spirit allow me to put forward a short list of matters that a revised proposal should do, at a minimum: * Walter has posted about a few issues with various parts of the proposal. Those should be addressed. * The "Reference" section does good to mention the issues, but the litany of forum discussions has no value besides "there have been repeated discussion in community forums of the topic", and refer to a list in an bibliography. Placing them in the "Reference" section suggests the reader that they need to read the forum debates in order to understand the DIP, which isn't and shouldn't be the case. * An "Existing Work" section discussing C++ (and possibly Rust) is a must. Studious neglect of what other languages do and what problems they have does not serve us well. I think Walter could help with that. * The "Rationale" section currently focuses only on issues caused by the current rule. It should have three parts: - Open with a brief description of the current rule and why it is that way. Here we have the advantage that confusing conversions are disallowed. - Then continue with "However, the binding rule also
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 9:10 PM, Manu wrote: * Its own author seems to not have an understanding of what the DIP proposes. More classy comments. I can't get enough of the way you belittle people. You're right. I have deleted this post a few seconds after having sent it on account of that remark, but somehow it got resuscitated. Please accept my apologies.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/30/19 1:29 PM, Manu wrote:
On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
Digitalmars-d-announce wrote:
On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
Why are you so stuck on this case? The DIP is about accepting rvalues,
not lvalues...
Calling with 'p', an lvalue, is not subject to this DIP.
The result of a CastExpression is an rvalue. An implicit cast is a
compiler-inserted CastExpression. Therefore all lvalues with a potential
implicit cast are rvalues.
But there's no existing language rule that attempts to perform an
implicit cast where an lvalue is supplied to a ref arg...?
That's exactly what lowerings are for: to precisely specify what should
happen when the proposed construct is used. DIP 1016 proposes a lowering
of the form:
{
T __temp0 = expr;
fun(__temp0);
}
In the first step, an implicit conversion of an lvalue may take place.
Why is the cast being attempted? 'p' is an lvalue, and whatever that
does should remain exactly as is (ie, emits a compile error).
Not according to DIP 1016. Here is an example pasted from it:
This inconvenience extends broadly to every manner of rvalue passed to
functions, including:
...
fun(my_short); // implicit type conversions (ie, short->int promotion)
Presumably my_short is a variable of type short. Is that correct?
Again (this is not a rhetorical or sarcastic question): are you sure DIP
1016 expresses what you are trying to accomplish?
We could perhaps allow this for `const` args, but that feels like
separate follow-up work to me, and substantially lesser value. This
DIP doesn't want to change anything about lvalues.
What we have here is:
* DIP 1016 proposes a hole in the language one could drive a truck through.
* The problem goes undetected in community review.
* Its own author seems to not have an understanding of what the DIP
proposes.
Andrei
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/30/19 3:34 AM, Kagamin wrote: On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote: Where should the temporary go? Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary. My bad, I overloaded the term "temporary". I meant the variable inserted by the lowering.
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/29/19 10:57 AM, Adam D. Ruppe wrote:
On Tuesday, 29 January 2019 at 15:48:23 UTC, Andrei Alexandrescu wrote:
On 1/29/19 10:44 AM, Nicholas Wilson wrote:
if (auto val = expr(); val) { ... },
Since we don't have these constructs, lowering would need to explain
what happens here.
Nitpick, but D has something very similar to that:
if(auto val = expr()) { ... }
it just depends on val implicitly casting to bool.
It's okay if the resulting code is ugly, it won't be user-visible.
We do have to be careful about this - error messages sometimes leak that
ugly code out.
Yah, it did happen in the past that implementations have been switched
from lowering to a dedicated case. Lowerings do remain a terrific tool
for conveying semantics and DIP authors should not worry about
implementation details.
Re: DIP 1016 should use expression lowering, not statement lowering
On 1/29/19 10:44 AM, Nicholas Wilson wrote:
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote:
While writing this example:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof))
{
assert(a.length == 200);
}
=>
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}
I noticed a problem - the lowering as informally described in DIP 1016
makes it difficult to figure how function calls present in control
statements like if, while, etc. should behave. Where should the
temporary go? An expression-based lowering clarifies everything. A
statement-based lowering would need to work on a case basis for all
statements involving expressions.
On the contrary, an expression lowering cannot inject temporary
declarations and is impossible.
The correct lowering in the case for `if` & friends follows the form of
C++ initialiser conditions(?) i.e:
if (auto val = expr(); val) { ... },
Since we don't have these constructs, lowering would need to explain
what happens here. Not difficult, but would be nice if we could avoid.
or the slightly more ugly valid D:
if ((){return expr(); }()) { ... }
this lambdification will work for just about anything: if, while, assert...
Yes, converting to lambdas is nice and easy and requires no statement
enumeration - just lower expressions to lambdas and be done with it.
It's okay if the resulting code is ugly, it won't be user-visible.
DIP 1016 should use expression lowering, not statement lowering
While writing this example:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof))
{
assert(a.length == 200);
}
=>
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}
I noticed a problem - the lowering as informally described in DIP 1016
makes it difficult to figure how function calls present in control
statements like if, while, etc. should behave. Where should the
temporary go? An expression-based lowering clarifies everything. A
statement-based lowering would need to work on a case basis for all
statements involving expressions.
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/29/19 6:45 AM, Andrei Alexandrescu wrote: It is truly remarkable that DIP 1016 provides not only a solution to the problem, but almost neglects to mention it. Meant "...not only no solution..."
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/29/19 3:35 AM, Manu wrote:
1. All of this is more useful criticism than the official and final
criticism affixed to the rejection, which when revised to remove the
incorrect criticisms, is basically left with the text "The Language
Maintainers found other issues with the proposal, most of which may
have been remedied through simple revision"
No. This is a nonnegotiable matter:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails
The code above should not compile. The DIP allows it to compile. We
didn't see how the DIP can be lightly edited to fix this problem, so we
recommended a complete rethinking and rewrite.
2. All of this criticism could have been given at any point in the
past half a year or so prior to submission, and that would have been
appreciated, rather than wasting our time.
We have given this criticism ever since ten years ago when you brought
the matter up. Literally every time, including in person. Whenever you
said "why not bind rvalues to ref?" we religiously replied with
(paraphrased of course) "We are worried about rvalues resulting from
implicit conversion of lvalues. You'd need to find a solution to that."
It is truly remarkable that DIP 1016 provides not only a solution to the
problem, but almost neglects to mention it.
3. "It does not influence our decision and should not be construed as
an essential aspect of the review" <-- Then why did it feature as
one of just 3 core criticism in the rejection text? And supplied as
one of the 2 reasons that could not "have been remedied through simple
revision".
If the matter above can be resolve through simple revision that would be
great. I don't think it can, but would love to be proven wrong!
4. "Under DIP 1016, a call with any T[] will silently "succeed" by
converting the slice to void[]" <-- Do you mean "... with any T[]
rvalue ..."? What would be the aim of that call? Can you suggest a
particularly sinister construction?
I am talking about this:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof)
{
assert(a.length == 200);
}
By applying the lowering rules in the DIP (including your pending
revision), the code is lowered to:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}
The code is far from sinister. But the assertion will fail.
I want to make sure there is mutual understanding that:
1. DIP 1016 proposes this semantics
2. We do not accept this semantics
Even if there is no agreement with (2), these are facts that I want to
make sure are understood by everyone involved - you, us, the rest of the
community.
5. "and recommended that it be rewritten simply because it would be
easier and would engender a stronger DIP." <-- I wrote the DIP I
wrote... your official feedback affixed to the bottom of the DIP was
pretty much entirely unhelpful, almost offensively so. I would just
write the same DIP if I started again. I genuinely hope someone can be
bothered to do this. After 10 years on this, I think I'm over it.
I am sorry you found the review unfit for your needs. I thought it puts
the main matter plain and simple: we do not accept code like this:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails
Honest, I don't think you have spent 10 years on this DIP. It is not
thorough work and fails to address the main problem it was supposed to
address: The one above.
6. "This result was frustrating and disheartening on our side, too: a
stronger DIP ..." <-- I'm sorry you hated it. You could have
reviewed it at any point, made suggestions at any point, written it
yourself, or encouraged someone competent to do it.
We didn't hate it. We made suggestions literally every time you brought
up the issue over the past decade. For my part, I have no idea what more
input I could have provided. "Solve the rvalues coming from implicit
conversions" is all feedback the DIP needs.
7. Your general tone is superior, as usual.
No need to attempt to make this personal, and claim the moral ground in
the process. Nobody is after you. We all want the D language to become
better. The DIP is not good. This is what it is.
All is not lost - the DIP is a good inspiration for a couple of ideas
that deserve investigation. It seems that allowing _only_ rvalues to be
bound to ref may work. I'm cautious because there may be cases we didn't
think of.
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/29/19 6:38 AM, Nicholas Wilson wrote: On Tuesday, 29 January 2019 at 08:35:11 UTC, Manu wrote: 4. "Under DIP 1016, a call with any T[] will silently "succeed" by converting the slice to void[]" <-- Do you mean "... with any T[] rvalue ..."? What would be the aim of that call? Can you suggest a particularly sinister construction? I _think_ what is meant is: void[] allocate(size_t size); bool reallocate(ref void[] b, size_t s); void deallocate(ref void[]); T[] arr = allocate(42); arr.reallocate(8192); // reallocates a temporary as T[] is cast to void arr.deallocate(); // double free Affirmative. (Just wrote about the same in another post). Thanks very much. Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/29/19 1:01 AM, Manu wrote:
This DIP is about passing rvalues to ref... so the issue you describe
passing lvalues to ref does not apply here.
There is no suggestion to change lvalue rules anywhere in this DIP.
The problem is with rvalues resulting as temporaries from lvalues. As in:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // oops
This is a smoking gun. If DIP 1016 does not propose allowing the code
above, it has caused a gross misunderstanding. Similarly, you mention in
a different response:
4. "Under DIP 1016, a call with any T[] will silently "succeed" by
converting the slice to void[]" <-- Do you mean "... with any T[]
rvalue ..."? What would be the aim of that call? Can you suggest a
particularly sinister construction?
If your intent was to NOT allow rvalues resulting from conversions, it
didn't come through at all. On the contrary, some examples suggest DIP
1016 _does_ allow it, as in this example:
This inconvenience extends broadly to every manner of rvalue passed to
functions, including:
...
fun(my_short); // implicit type conversions (ie, short->int promotion)
The reader assumes since the DIP characterizes passing a short lvalue to
a ref int is an inconvenience, the DIP has set out to resolve it.
The lowering rules proposed by DIP 1006 prescribe the following:
void bump(ref int x) { ++x; }
short y = 42;
bump(y);
===>
void bump(ref int x) { ++x; }
short y = 42;
{
int __temp0 = y;
bump(__temp0);
}
So... yes, lvalues do (undesirably) get converted to rvalues of a
different type according to the DIP.
Are you sure the DIP expresses what you are trying to accomplish?
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/28/19 5:23 PM, Steven Schveighoffer wrote: I already see this kind of bug all the time with alias this. Can you please post more detail? It may be of relevance to future work.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/28/19 1:00 PM, Andrei Alexandrescu wrote:
On 1/24/19 3:01 PM, kinke wrote:
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
We discussed and concluded that one mechanism to mitigate this issue
was already readily available, and it's just that 'out' gains a much
greater sense of identity (which is actually a positive side-effect if
you ask me!).
You have a stronger motivation to use 'out' appropriately, because it
can issue compile errors if you accidentally supply an rvalue.
`out` with current semantics cannot be used as drop-in replacement for
shared in-/output ref params, as `out` params are default-initialized
on entry. Ignoring backwards compatibility for a second, I think
getting rid of that would actually be beneficial (most args are
probably already default-initialized by the callee in the line above
the call...) - and I'd prefer an explicitly required `out` at the call
site (C# style), to make the side effect clearly visible.
I'd have otherwise proposed a `@noRVal` param UDA, but redefining
`out` is too tempting indeed. ;)
It seems to me that a proposal adding the "@rvalue" attribute in
function signatures to each parameter that would accept either an rvalue
or an lvalue would be easy to argue.
- No exposing existing APIs to wrong uses
- The function's writer makes the decision ("I'm fine with this function
taking an rvalue")
- Appears in the function's documentation
- Syntax is light and localized where it belongs
- Scales well with number of parameters
- Transparent to callers
Whether existing keyword combinations ("in", "out", "ref" etc) could be
used is a secondary point.
The advantage is there's a simple and clear path forward for API
definition and use.
Andrei
One more thought.
The main danger is restricted to a specific conversion: lvalue of type T
is converted to ref of type U. That way both the caller and the function
writer believe the value gets updated, when in fact it doesn't. Consider:
real modf(real x, ref real i);
Stores integral part in i, returns the fractional part. At this point
there are two liabilities:
1. User passes the wrong parameter type:
double integral;
double frac = modf(x, integral);
// oops, integral is always NaN
The function silently converts integral from double to real and passes
the resulting temporary into the function. The temporary is filled and
lost, leaving user's value unchanged.
2. The API gets changed:
// Fine, let's use double
real modf(real x, ref double i);
At this point all correct callers are silently broken - everybody who
correctly used a real for the integral part now has their call broken
(real implicitly converts to a double temporary, and the change does not
propagate to the user's value).
(If the example looks familiar it may be because of
https://dlang.org/library/std/math/modf.html.)
So it seems that the real problem is that the participants wrongly
believe an lvalue is updated.
But let's say the caller genuinely doesn't care about the integral part.
To do so is awkward:
real unused;
double frac = modf(x, unused);
That code isn't any better or less dangerous than:
double frac = modf(x, double());
Here the user created willingly created an unnamed temporary of type
double. Given that there's no doubt the user is not interested in that
value after the call, the compiler could (in a proposed semantics) allow
the conversion of the unnamed temporary to ref.
TL;DR: it could be argued that the only dangerous conversions are lvalue
-> temp rvalue -> ref, so only disable those. The conversion rvalue ->
temp rvalue -> ref is not dangerous because the starting value on the
caller side could not be inspected after the call anyway.
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/24/19 3:01 PM, kinke wrote:
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
We discussed and concluded that one mechanism to mitigate this issue
was already readily available, and it's just that 'out' gains a much
greater sense of identity (which is actually a positive side-effect if
you ask me!).
You have a stronger motivation to use 'out' appropriately, because it
can issue compile errors if you accidentally supply an rvalue.
`out` with current semantics cannot be used as drop-in replacement for
shared in-/output ref params, as `out` params are default-initialized on
entry. Ignoring backwards compatibility for a second, I think getting
rid of that would actually be beneficial (most args are probably already
default-initialized by the callee in the line above the call...) - and
I'd prefer an explicitly required `out` at the call site (C# style), to
make the side effect clearly visible.
I'd have otherwise proposed a `@noRVal` param UDA, but redefining `out`
is too tempting indeed. ;)
It seems to me that a proposal adding the "@rvalue" attribute in
function signatures to each parameter that would accept either an rvalue
or an lvalue would be easy to argue.
- No exposing existing APIs to wrong uses
- The function's writer makes the decision ("I'm fine with this function
taking an rvalue")
- Appears in the function's documentation
- Syntax is light and localized where it belongs
- Scales well with number of parameters
- Transparent to callers
Whether existing keyword combinations ("in", "out", "ref" etc) could be
used is a secondary point.
The advantage is there's a simple and clear path forward for API
definition and use.
Andrei
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 1/24/19 2:18 AM, Mike Parker wrote: Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted. You can read a summary of the Formal Assessment at the bottom of the document: https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md Hi everyone, I've followed the responses to this, some conveying frustration about the decision and some about the review process itself. As the person who carried a significant part of the review, allow me to share a few thoughts of possible interest. * Fundamentally: a DIP should stand on its own and be judged on its own merit, regardless of rhetoric surrounding it, unstated assumptions, or trends of opinion in the forums. There has been a bit of material in this forum discussion that should have been argued properly as a part of the DIP itself. * The misinterpretation of the rewrite (expression -> statement vs. statement -> statement) is mine, apologies. (It does not influence our decision and should not be construed as an essential aspect of the review.) The mistake was caused by the informality of the DIP, which shows rewrites as a few simplistic examples instead of a general rewrite rule. Function calls are expressions, so I naturally assumed the path would be to start with the function call expression. Formulating a general rule as a statement rewrite is possible but not easy and fraught with peril, as discussion in this thread has shown. I very much recommend going the expression route (e.g. with the help of lambdas) because that makes it very easy to expand to arbitrarily complex expressions involving function calls. Clarifying what temporaries get names and when in a complex expression is considerably more difficult (probably not impossible but why suffer). * Arguments of the form: "You say DIP 1016 is bad, but look at how bad DIP XYZ is!" are great when directed at the poor quality of DIP XYZ. They are NOT good arguments in favor of DIP 1016. * Arguments of the form "Functions that take ref parameters just for changing them are really niche anyway" should be properly made in the DIP, not in the forums and assumed without stating in the DIP. Again, what's being evaluated is "DIP" not "DIP + surrounding rhetoric". A good argument would be e.g. analyzing a number of libraries and assess that e.g. 91% uses of ref is for efficiency purposes, 3% is unclear, and only 6% is for side-effect purpose. All preexisting code using ref parameters written under the current rule assumes that only lvalues will be bound to them. A subset of these functions take by ref for changing them only. The DIP should explain why that's not a problem, or if it is one it is a small problem, etc. My point is - the DIP should _approach_ the matter and build an argument about it. One more example from preexisting code for illustration, from the standard library: // in the allocators API bool expand(ref void[] b, size_t delta); bool reallocate(ref void[] b, size_t s); These primitives modify their first argument in essential ways. The intent is to fill b with the new slice resulted after expansion/reallocation. Under the current rules, calling these primitives is cumbersome, but usefully so because the processing done requires extra care if typed data is being reallocated. Under DIP 1016, a call with any T[] will silently "succeed" by converting the slice to void[], passing the temporary to expand/reallocate, then return as if all is well - yet the original slice has not been changed. The DIP should create a salient argument regarding these situations (and not only this example, but the entire class). It could perhaps argue that: - Such code is bad to start with, and should not have been written. - Such code is so rare, we can take the hit. We then have a recommendation for library writers on how to amend their codebase (use @disable or some other mechanisms). - The advantages greatly outweigh this problem. - The bugs caused are minor easy to find. - ... Point being: the matter, again should be _addressed_ by the DIP. * Regarding our recommendation that the proposal is resubmited as a distinct DIP as opposed to a patch on the existing DIP: this was not embracing bureaucracy. Instead, we considered that the DIP was too poor to be easily modified into a strong proposal, and recommended that it be rewritten simply because it would be easier and would engender a stronger DIP. * Regarding the argument "why not make this an iterative process where concerns are raised and incrementally addressed?" We modeled the DIP process after similar processes - conference papers, journal papers, proposals in other languages. There is a proposal by one
Top Five World’s Most Underrated Programming Languages
Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html
Re: My Meeting C++ Keynote video is now available
On 1/12/19 7:21 PM, Bastiaan Veelo wrote: On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei Top notch, as usual. Nice progression from “another language” through “the other language”, “d (other) language” to finally just “D language“ :-) Bastiaan. Glad you noticed. It was deliberate.
My Meeting C++ Keynote video is now available
https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei
Shopping on Amazon on Prime Day (and beyond)? Support the D language!
Amazon has a nonprofit arm: https://smile.amazon.com Go there and choose The D Language Foundation as your charity of choice, then shop normally through smile.amazon.com. A fraction of your expenditure will go to the Foundation. Thanks, Andrei
Vision document for H1 2018
Hello, the vision document of the Founation for the first six months of 2018 is here: https://wiki.dlang.org/Vision/2018H1 In addition to the expected items, we have a new top-level priority - locking down the language definition. This is in recognition of the fact that we need a precise definition of the language going forward. Thanks, Andrei
Re: An optional/maybe type with range semantics
On 2/28/18 12:54 PM, Andrei Alexandrescu wrote: On 2/25/18 8:03 PM, aliak wrote: Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or features, or bad design or potential for better designs from anyone who's interested :) Code: https://github.com/aliak00/optional Dub: https://code.dlang.org/packages/optional Docs: https://aliak00.github.io/optional/ Did you take a look at https://dlang.org/library/std/range/only.html? -- Andrei Ah, sorry I missed that you mentioned it. -- Andrei
Re: An optional/maybe type with range semantics
On 2/25/18 8:03 PM, aliak wrote: Alo, Just finished up a first take on an optional type for D. It's essentially a mix of Nullable and std.range.only, but with a lot more bells and whistles. I would love to hear any feedback on code, or features, or bad design or potential for better designs from anyone who's interested :) Code: https://github.com/aliak00/optional Dub: https://code.dlang.org/packages/optional Docs: https://aliak00.github.io/optional/ Did you take a look at https://dlang.org/library/std/range/only.html? -- Andrei
Please submit to DConf 2018!
With the Feb 25 deadline looming, allow me to holler to everyone who has worked on great things in the D language through the past year: please make a DConf 2018 submission! By all measures there's been significant pick up in contributions to the D language during the recent months, and it would be awesome to have that solid work reflected in a strong program in Munich. What we need on Feb 25 are your title, abstract, and bio. What we need on your talk day is your lovable self talking about your great idea. Giving a talk at DConf is a high service to the D language community. In recognition of that, the D Language Foundation reimburses travel and accommodation expenses for speakers. Please contact Michael Parker (soc...@dlang.org) for details. Thanks, Andrei
Re: D's Newfangled Name Mangling
On 12/20/17 8:57 AM, Mike Parker wrote: Many thanks to Rainer for his insightful new article for the D Blog outlining the new name mangling algorithm. He talks about the old implementation and its limitations before going into the details of the new one. It's a topic I had never considered digging into before, even when the big Voldemort issue first popped up, but now I find it interesting. The blog https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Reddit https://www.reddit.com/r/programming/comments/7l1h36/ds_newfangled_name_mangling/ Hi folks, the discussion in the announce forum is most welcome but statistically very few people read the forum. Please direct discussions to the reddit group, which enjoys a broader audience. Sadly right now the sparse reddit discussion makes the reception look worse than it actually was. -- Andrei
Meet our new scholarship recipient, Alexandru Jercaianu
Hello everyone, it is my pleasure to announce that Alexandru Jercaianu, a starting MSc student at University "Politehnica" Bucharest, is recipient of our scholarship. Alex is up and running working on his bootcamp tasks. Currently he is attempting unsuccessfully to post in our general group :o). Please join me in welcoming Alexandru! Andrei
Re: Boston D Meetup: Strawman Structs
On 7/25/17 5:50 AM, John Colvin wrote: On Sunday, 2 July 2017 at 10:35:49 UTC, Steven Schveighoffer wrote: I'll have a short presentation on a weird trick I discovered while writing some MySQL serialization code. Hope you can attend! https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 -Steve Is there a written summary of the idea? Or is there a specific point in the video someone could point me to? What I can definitely say is it's a very interesting technique worth slogging through probably poor audio etc. It's really a concept language without a language. Very inspiring work. -- Andrei
Re: H2 2017 Vision Document
On Tuesday, 25 July 2017 at 15:09:37 UTC, Mike Parker wrote: On Tuesday, 25 July 2017 at 14:16:18 UTC, Atila Neves wrote: How would one go about volunteering? Atila I think you just did. Atila, welcome to Team Phobos.
Re: DIP 1010--Static foreach--Accepted
On 7/17/17 8:38 AM, Steven Schveighoffer wrote: What is the resolution of how break statements affect static foreach/foreach? We initially allowed break and continue to refer to the enclosing statement, but upon further consideration we will make it an error. This allows us to collect more experience with the feature and leaves us the option to permit break/continue later on. I have contacted Timon about the matter. Thanks! -- Andrei
static foreach is now in github master
For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei
Re: Munich D Meetup July 2017
On 7/14/17 5:32 PM, Dragos Carp wrote: Bump the thread, the next Munich D Meetup is getting closer. Greetings to the D community in München, which seems to be our strongest local group. Hoping for a solid turnout at this meeting because it may prompt a larger event later on. Would be happy to visit and give a talk in the fall! I'll let the local leaders give folks more information at the upcoming meetup. -- Andrei
Re: DIP 1010--Static foreach--Accepted
On 7/16/17 9:10 AM, Mike Parker wrote: Congratulations to Timon Gehr. Not only was his "Static foreach" DIP accepted, it picked up a good deal of praise from Walter & Andrei. Indeed. Kudos to Timon (and thanks Mike for driving the process). This is a well done DIP that many others could draw inspiration from. -- Andrei
RedMonk language rankings June 15, 2017
http://i-programmer.info/news/98-languages/10859-redmonk-rankings-reveal-the-languages-we-love.html -- Andrei
Article on i-programmer.info on GDC
http://i-programmer.info/news/98-languages/10883-d-gets-a-boost-from-gcc.html Andrei
Re: Ali's talk C++Now 2017: Competitive Advantage with D on Reddit!
On 6/8/17 5:03 PM, Wulfklaue wrote: On Thursday, 8 June 2017 at 20:38:33 UTC, Ali Çehreli wrote: That link doesn't work for me. Besides, I've heard that it's better not to click through a link as HN either rates it lower or flags it as spam. Not sure though, I'm just contributing to cargo cult... :) Ali Removed the old one and add new one with the full youtube link: https://news.ycombinator.com/item?id=14517183 Posting direct HN links in any forum is a sure way to have the entry classified as spam (HN uses an algorithm that flags as spam many accesses that do not have their own site as referrer). -- Andrei
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 06/03/2017 11:08 AM, Andrei Alexandrescu wrote: On 6/2/17 10:17 AM, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Congrats to all who worked on this. Next step is to revise the DIP that puts the approved option to the fore and mentions the others only as other options that have been analyzed. This is because we have an "Approved" status but not "Approved Option X". Thanks! -- Andrei Sorry, was looking at a stale copy. I think the DIP is fine as is. The previously discussed options are available as earlier revisions of the DIP. -- Andrei
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On 6/2/17 10:17 AM, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Congrats to all who worked on this. Next step is to revise the DIP that puts the approved option to the fore and mentions the others only as other options that have been analyzed. This is because we have an "Approved" status but not "Approved Option X". Thanks! -- Andrei
Re: DCompute is now in the master branch of LDC
On 5/31/17 6:03 PM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wednesday, May 31, 2017 18:55:14 bachmeier via Digitalmars-d-announce wrote: On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote: But can we please reduce the bike shedding Marketing is only bike shedding if you don't care how many people make use of your work. That may be true, but given how this was supposed to be a thread on some great news about this cool library, having most of the posts be about the name has got to be frustrating. Yes, the name matters, but this thread has been pretty thoroughly derailed from its original purpose. - Jonathan M Davis You're right. Congratulations Nicholas for this great work and I wish it succeeds by any name he chooses for it. -- Andrei
Re: DCompute is now in the master branch of LDC
On 5/31/17 7:28 PM, Nicholas Wilson wrote: On Wednesday, 31 May 2017 at 22:15:33 UTC, Wulfklaue wrote: On Wednesday, 31 May 2017 at 12:28:47 UTC, Nicholas Wilson wrote: Perhaps there will be scope for renaming if/when this also includes graphics when either OpenCL is merged into the Vulkan API or Petar Kirov gets Vulkan SPIRV generation going on LLVM, but for now the name stays. People who GPU program are indeed a small group. But you do NOT entice other people to try it, when they do not even know a language has this feature set. And this comes down to marketing. Lets post "D has DCompute" or "D has D-GPU"... on Reddit, ycombinator and other forum or news site. What do you think people will more likely click on? So you don't post either of those titles and instead post "D has DCompute: Native heterogeneous computing on GPUs and more, hassle free!" "D has the invariant qualifier: It means immutable".
Re: DCompute is now in the master branch of LDC
On 5/30/17 3:23 PM, Jack Stouffer wrote: On Tuesday, 30 May 2017 at 18:06:56 UTC, Walter Bright wrote: I fear the conversation will go like this, like it has for me: N: DCompute W: What's DCompute? N: Enables GPU programming with D W: Cool! instead of: N: D-GPU W: Cool! I can use D to program GPUs! This was literally what happened to me when I saw the headline. I'm in the same camp, and I have a passing familiarity with the domain. Worse, only one day after the talk I'd already forgotten and thought DCompute does what DHDL does. It seems there are two paths - either choose an unrelated name and push it as a brand (e.g. Amazon, Google, and in our community Phobos or Vibe), or choose a name that immediately establishes the library as "the D approach to GPGPUs". The name "DCompute" is in an unfortunate corner of the branding space. Andrei
