Re: Beta 2.086.0

2019-04-20 Thread Walter Bright via Digitalmars-d-announce
On 4/20/2019 7:16 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. Martin, thank you for the invaluable but thankless job of managing the releases!

Re: Using const to Enforce Design Decisions

2019-03-28 Thread Walter Bright via Digitalmars-d-announce
On 3/26/2019 12:57 AM, Marco de Wild wrote: I've also tried to use pure, but (ironically) I found it harder to use. I think it's easier to understand when an object will be mutated or not than to predict whether there are side effects. Using pure is indeed hard. One has to make a change in

Phobos now compiling with -dip1000

2019-03-22 Thread Walter Bright via Digitalmars-d-announce
Many thanks to Sebastian Wilzbach, Nicholas Wilson, Mike Franklin, and others! It's been a long and often frustrating endeavor, but we made it and I'm very pleased with the results.

Re: DConf 2019 Schedule

2019-03-18 Thread Walter Bright via Digitalmars-d-announce
On 3/18/2019 8:55 AM, Robert M. Münch wrote: Typo in Walter's abstract: ... "D supports a number of techniques for allocating meory." => memory I should stop trusting the cat to review my work.

Re: Blog post on the joys of hand-translating C++'s std::function to D

2019-03-07 Thread Walter Bright via Digitalmars-d-announce
On 3/7/2019 9:27 AM, Mike Parker wrote: On Thursday, 7 March 2019 at 15:45:50 UTC, Atila Neves wrote: C++ is hard: https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/ Reddit:

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-27 Thread Walter Bright via Digitalmars-d-announce
On 2/27/2019 3:27 AM, Jacob Carlborg wrote: [...] Please start another thread.

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-26 Thread Walter Bright via Digitalmars-d-announce
On 2/26/2019 2:32 AM, Jacob Carlborg wrote: What about the __mutable proposal [1]? [1] https://github.com/dlang/dmd/pull/8315 It hasn't been approved yet, and please start another thread if you want to discuss it.

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 7:17 PM, Manu wrote: break my DIP The review process is not about "why not add this feature" , but "why should we have this feature". Additionally, it is most assuredly about finding flaws in it. Isn't it best to find out the flaws before going further with it than finding

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 7:17 PM, Manu wrote: I'm literally astonished that it's been agreed it's fine that a copy constructor can mutate the source... and I can't help but draw contrast to the exact same sorts of arguments that people were using to break my DIP, Mutating the lvalue ref was not the issue,

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 3:05 PM, Olivier FAURE wrote: On Monday, 25 February 2019 at 22:45:38 UTC, Olivier FAURE wrote: For the same reason C++'s std::shared_pointer uses a non-const copy constructor. Wait, no, I just checked, std::shared_pointer's copy constructor is const, even though it changes

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 10:44 AM, Andrei Alexandrescu wrote: 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

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 6:55 PM, Andrei Alexandrescu wrote: If there's something else I can do to atone, please let me know. Pistols at dawn? Or better yet, why don't I buy both of you a beer at DConf?

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 8:22 AM, H. S. Teoh wrote: I disagree. Logical const means the outside world can't tell that the object has changed, because only a constant value is ever seen from outside. This is the basis of lazy initialization (which is part of the concept of lazy evaluation), an important

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 7:45 AM, Atila Neves wrote: I have no idea what people are talking about when they mention on this forum that D's const is useless. Nearly every function parameter in my code is `in`. Nearly every variable declaration uses `const` instead of `auto`, the main exception being when a

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 3: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

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-25 Thread Walter Bright via Digitalmars-d-announce
On 2/25/2019 6:26 PM, Andrei Alexandrescu wrote: 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. I approved it.

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
On 2/24/2019 8:04 PM, Manu wrote: 1. make code easier to understand? const code is self documenting and protective against modification by issuing the user helpful error messages. I've had many people tell me they mean transitive const when they use const in C++. That is not self

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
Your DIP, and nobody else is going to do it, so it falls to me. BTW, everyone should expect the DIP process to be brutal. It has to be, we're long past the stage where we can allow misshapen stuff to get into the language. Nobody was very kind with my bottom type DIP :-) You should read the

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
I agree with your point that C++ const can be used in a lot more places than D const. Absolutely true. Missing from the post, however, is an explanation of what value C++ const semantics have. How does it: 1. make code easier to understand? 2. prevent common programming bugs? 3. help with

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
The problem with C++ const is it only goes one level, i.e. what I call "head-const". If you pass a T to a const parameter, anything T references remains mutable. It's more of a suggestion than anything reliable or enforceable. It only works if your data structures are simple aggregates, not

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
Thanks for letting me know you're abandoning the rvalue ref DIP. I had held off working on it because I didn't want to duplicate efforts; we're short-staffed enough as it is.

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
On 2/24/2019 1:02 PM, Manu wrote: I mean like, my DIP was almost violently rejected, If it makes you feel any better, Razvan had to endure major rewrites of both the dip and the implementation.

Re: DIP 1018--The Copy Constructor--Formal Review

2019-02-24 Thread Walter Bright via Digitalmars-d-announce
On 2/24/2019 1:02 PM, Manu wrote: I mean like, my DIP was almost violently rejected, I thought it was clear what was needed to be done with it, and I thought you were going to rewrite it. Was I mistaken? but in here there's text like this: "The parameter of the copy constructor is passed

Re: Beta 2.085.0

2019-02-16 Thread Walter Bright via Digitalmars-d-announce
Thank you, Martin!

Re: New Blog Post: Writing a D Wrapper for a C Library

2019-02-10 Thread Walter Bright via Digitalmars-d-announce
On 2/10/2019 6:19 AM, Mike Parker wrote: Victor Porton decided to port an app he developed for a research project from Ada to D. In the process, he created a bindings and a wrapper for a C library, librdf. In this post, he shares the approach he took to translating the C API into the D

Re: 5 reasons the D programming language is a great choice for development

2019-02-07 Thread Walter Bright via Digitalmars-d-announce
On 2/6/2019 11:53 AM, aberba wrote: I've gotten preoccupied lately with startup stuff and other form distractions, but I hope to be able to write more D related articles and tutorials on my blog (aberba.netlify.com) and other mediums this year. Great! Keep 'em coming!

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-31 Thread Walter Bright via Digitalmars-d-announce
On 1/31/2019 1:46 PM, Andrei Alexandrescu wrote: 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. That's why it's problematic to have a rule that rvalues can be

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-31 Thread Walter Bright via Digitalmars-d-announce
On 1/30/2019 5:55 PM, Manu wrote: lets replace 10 with a short variable named: S "a short variable named: S" is an lvalue, so why would the rewrite be attempted? S must be an rvalue for any rewrite to occur. We're talking about rvalues here. This illustrates why this should be compared with

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-29 Thread Walter Bright via Digitalmars-d-announce
On 1/29/2019 3:45 AM, Andrei Alexandrescu wrote: 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); } Even simpler: void func(ref void* p) { free(p); // frees

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-29 Thread Walter Bright via Digitalmars-d-announce
On 1/28/2019 10:10 PM, Manu wrote: Furthermore, D has these match levels: 1. exact 2. const 3. conversion 4. no match If there are two or more matches at the same level, the decision is made based on partial ordering. How does adding the new ref/value overloading fit

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-26 Thread Walter Bright via Digitalmars-d-announce
On 1/26/2019 8:28 AM, Rubn wrote: [...] The point is, the DIP needs to spell this out in an organized and complete fashion, like any proper spec does. We all want a better specified language, let's make it happen.

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-25 Thread Walter Bright via Digitalmars-d-announce
On 1/25/2019 7:44 PM, Manu wrote: I never said anything about 'rvalue references', The DIP mentions them several times in the "forum threads" section. I see you want to distinguish the DIP from that; I recommend a section clearing that up. However, my points about the serious problems with

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-25 Thread Walter Bright via Digitalmars-d-announce
On 1/25/2019 2:57 AM, kinke wrote: On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote: On 1/24/2019 1:03 PM, kinke wrote: (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy); There must be an individual gate for each of __pfx and

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-25 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 11:53 PM, Nicholas Wilson wrote: That the conflation of pass by reference to avoid copying and mutation is not only deliberate but also mitigated by @disable. The first oddity about @disable is it is attached to the foo(int), not the foo(ref int). If I wanted to know if foo(ref

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
No, it is not rejected in principle. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it. For example, I spent a lot of time working on ARC, and was all set to move forward with it when Timon stepped in and showed it

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 12:01 PM, kinke wrote: `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...) The

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 4:21 PM, Elie Morisse wrote: I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection. On the contrary. It is good to find conceptual errors before implementing it. They're a LOT cheaper to fix earlier rather than when it is in the field.

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 4:31 PM, 12345swordy wrote: And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here? Of course it's frustrating. On the other hand, we've had a lot of problems stemming from implementing features without thoroughly

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 1:03 PM, kinke wrote: (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy); There must be an individual gate for each of __pfx and pfy. With the rewrite above, if b() throws then _pfx won't be destructed. (All this rigamarole is

Re: DIP 1016--ref T accepts r-values--Formal Assessment

2019-01-24 Thread Walter Bright via Digitalmars-d-announce
On 1/24/2019 1:31 AM, Manu wrote: This process is pretty unsatisfying, because it ships off to a black-box committee, who were apparently able to misunderstand the substance of the proposal and then not seek clarification, and despite the only legitimate issue from my perspective being easily

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Walter Bright via Digitalmars-d-announce
On 1/17/2019 11:31 AM, H. S. Teoh wrote: [...] Thanks for the thoughtful and well-written piece. But there is a counterpoint: symmetry in mathematics is one thing, but symmetry in human intuition is not. Anytime one is dealing in human interfaces, one runs into this. I certainly did with

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-17 Thread Walter Bright via Digitalmars-d-announce
On 1/17/2019 8:06 AM, bpr wrote: Was that a pre C++11 version of C++, or a more modern one? pre C++11

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-16 Thread Walter Bright via Digitalmars-d-announce
On 1/16/2019 4:19 PM, H. S. Teoh wrote: On Wed, Jan 16, 2019 at 11:43:19PM +, John Carter via Digitalmars-d-announce wrote: ...I do find it remarkable that I can read the d code quite easily without reaching for the reference manual, but to make sense of his C++, it sends me trawling

Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)

2019-01-16 Thread Walter Bright via Digitalmars-d-announce
On 1/16/2019 3:43 PM, John Carter wrote: Somebody on the C++ side has written a reply https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/ From the article: D (with corrections): static if (maxLength < 0xFFFE) { alias CellIdx = uint16_t; } else { alias CellIdx

Re: My Meeting C++ Keynote video is now available

2019-01-16 Thread Walter Bright via Digitalmars-d-announce
On 1/15/2019 11:39 AM, 12345swordy wrote: If there were a dip that involves deprecating class, I wouldn't worry about that getting very far :-)

Re: My Meeting C++ Keynote video is now available

2019-01-16 Thread Walter Bright via Digitalmars-d-announce
On 1/15/2019 11:08 PM, Nicholas Wilson wrote: I'm pretty sure Jacob is talking about a completely different type of macro (i.e. not textual substitution), AST macros. I understand he means AST macros, but they aren't fundamentally different in the characteristic I'm talking about. I'd be

Re: My Meeting C++ Keynote video is now available

2019-01-15 Thread Walter Bright via Digitalmars-d-announce
On 1/15/2019 10:39 AM, Jacob Carlborg wrote: Perhaps we shouldn't support user defined types or functions either ;) You deliberately wrote that, and I'm confident you'd never try to pass that off as good work. With macros, however, programmers are convinced they are creating models of

Re: My Meeting C++ Keynote video is now available

2019-01-15 Thread Walter Bright via Digitalmars-d-announce
On 1/15/2019 1:10 AM, Jacob Carlborg wrote: The AST macros I've been talking about have never been able to create new syntax. Template expressions can't, either, but what they do is hijack the syntax for completely different purposes. The poor reader will be looking at code, and it will

Re: My Meeting C++ Keynote video is now available

2019-01-14 Thread Walter Bright via Digitalmars-d-announce
On 1/14/2019 10:49 AM, Jacob Carlborg wrote: But Ddoc has macros ;) Indeed it does. But the macros cannot be used to create syntax, and there is no token concatenation. Macros cannot define other macros.

Re: My Meeting C++ Keynote video is now available

2019-01-13 Thread Walter Bright via Digitalmars-d-announce
On 1/13/2019 9:31 PM, Paul Backus wrote: Scheme is probably the language that takes this idea of a minimal "core language" with powerful metaprogramming facilities the furthest, and the result is a fragmented ecosystem that makes writing portable, non-trivial programs close to impossible. (See

Re: My Meeting C++ Keynote video is now available

2019-01-12 Thread Walter Bright via Digitalmars-d-announce
On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 One major takeaway is that the bugs/line are the same regardless of the language used. This means that languages that enable more expression in fewer lines of code result in fewer bugs for the same

Re: My Meeting C++ Keynote video is now available

2019-01-12 Thread Walter Bright via Digitalmars-d-announce
On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 Wonderful talk! The questions asked at the end were great, too.

Re: Release D 2.084.0

2019-01-05 Thread Walter Bright via Digitalmars-d-announce
On 1/2/2019 5:25 AM, Martin Nowak wrote: Glad to announce D 2.084.0, ♥ to the 53 contributors. Have we ever had 53 for one release before? Wow!

Re: [neovim/vim] ncm2/ncm2-d autocompletion source for d

2018-12-27 Thread Walter Bright via Digitalmars-d-announce
On 12/18/2018 2:12 PM, viniarck wrote: neovim/vim8 users out there, if you'd like to have an alternative to deoplete, ncm2 is async and really fast, works out of the box, and it has integration with UltiSnippets to further expand all the arguments of the completion in place. So far, I've been

Re: DConf 2019: Shepherd's Pie Edition

2018-12-25 Thread Walter Bright via Digitalmars-d-announce
On 12/25/2018 10:54 AM, Joakim wrote: [...] It's fine that you disagree with others, and it's ok when you insult me, but when you insult others it's time to stop.

Re: DConf 2019: Shepherd's Pie Edition

2018-12-24 Thread Walter Bright via Digitalmars-d-announce
On 12/24/2018 4:30 AM, Vijay Nayar wrote: I've been doing quite a bit of work this year on the Google S2 Geometric Library in D. If I can benchmark the library against the C++ version or show how it can be used to tackle some of the trickier real-time problems in large-scale web services,

Re: DConf 2019: Shepherd's Pie Edition

2018-12-24 Thread Walter Bright via Digitalmars-d-announce
On 12/24/2018 2:22 PM, Steven Schveighoffer wrote: I'm sure Walter and Andrei would not discourage more D conferences or conference-like gatherings. Speaking for myself (and I'm sure Andrei would agree) we're all for it.

Re: DConf 2019: Shepherd's Pie Edition

2018-12-23 Thread Walter Bright via Digitalmars-d-announce
On 12/23/2018 3:40 PM, Rubn wrote: I'll take that to assume you aren't paying for your own ticket, your own hotel expenses, etc. I wonder if you would feel differently about this if you had to pay for all these out of your own pocket. I paid my own expenses for DConf. So did many of the

Re: DConf 2019: Shepherd's Pie Edition

2018-12-23 Thread Walter Bright via Digitalmars-d-announce
On 12/23/2018 2:59 AM, Joakim wrote: I wish those organizing DConf would focus on that more. You're free to organize D meetups and conferences as you see fit. Heck, C++ has many conferences, run by different organizations with different ideas on how to do it. Nothing wrong with that. Even

Re: DConf 2019: Shepherd's Pie Edition

2018-12-23 Thread Walter Bright via Digitalmars-d-announce
On 12/23/2018 1:36 AM, Russel Winder wrote: If people want to have a DConf, it is not your position to tell them they cannot. No worries, we're full steam ahead on DConf 2019. I, for one, am greatly looking forward to it and seeing everybody.

Re: DConf 2019: Shepherd's Pie Edition

2018-12-23 Thread Walter Bright via Digitalmars-d-announce
On 12/22/2018 10:20 PM, Joakim wrote: Honestly, yours are routinely the worst presentations at DConf. Your strength as a presenter is when you dig deeply into a bunch of technical detail or present some new technical paradigm, similar to Andrei. Yet, your DConf keynotes usually go the exact

Re: DConf 2019: Shepherd's Pie Edition

2018-12-22 Thread Walter Bright via Digitalmars-d-announce
On 12/22/2018 7:11 AM, Joakim wrote: I've never been to DConf I suggest actually attending and seeing for yourself.

Re: DConf 2019: Shepherd's Pie Edition

2018-12-22 Thread Walter Bright via Digitalmars-d-announce
On 12/22/2018 6:26 AM, Atila Neves wrote: If you don't like conferences you don't have to go. I for one am excited about being in London in May. Please don't sour it for other who think/feel like I do. That's right. And hefting a pint with Atila is guaranteed to be a highlight of the

Re: DConf 2019: Shepherd's Pie Edition

2018-12-22 Thread Walter Bright via Digitalmars-d-announce
On 12/22/2018 5:33 AM, Russel Winder wrote: it's on at the exact same time as DevoxxUK 2019 which is at the Business Design Centre. :-( Please inform DevoxxUK they need to shift their schedule.

Re: Blog post: What D got wrong

2018-12-19 Thread Walter Bright via Digitalmars-d-announce
On 12/13/2018 10:29 AM, Adam D. Ruppe wrote: The attribute spam is almost longer than the function itself. Attributes only start to matter when creating code that will be around for a long time (such as reusable libraries). It's a waste of effort for short term code.

Re: This Week in D is back

2018-12-18 Thread Walter Bright via Digitalmars-d-announce
On 12/17/2018 2:01 PM, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Thank you, Adam!

Re: Blog post: What D got wrong

2018-12-17 Thread Walter Bright via Digitalmars-d-announce
On 12/15/2018 11:53 AM, Atila Neves wrote: @safe and pure though... @safe is not so hard to adopt, since by using @trusted one can proceed incrementally. Going pure, however, is much harder (at least for me) because I'm not used to programming that way. Making a function pure often

Re: Fuzzed - a program to find DMDFE parser crash

2018-12-15 Thread Walter Bright via Digitalmars-d-announce
On 12/15/2018 2:48 PM, Neia Neutuladh wrote: The way to fix this is to replace the entire parser and get rid of the idea of AST poisoning; at the first error, you give up on parsing the entire file. From there, you can try recovering from specific errors with proper testing. DMD tries to

Re: Fuzzed - a program to find DMDFE parser crash

2018-12-15 Thread Walter Bright via Digitalmars-d-announce
On 12/15/2018 3:29 AM, Basile B. wrote: The time to write this announce, already 5 "crashers" found. Great! Please post them to bugzilla.

Re: Blog post: What D got wrong

2018-12-11 Thread Walter Bright via Digitalmars-d-announce
On 12/11/2018 4:51 AM, Nicholas Wilson wrote: > Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For

Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System

2018-12-05 Thread Walter Bright via Digitalmars-d-announce
#4 on HackerNews front page! https://news.ycombinator.com/ 33 points at the moment!

Re: Heads Up: Use WCHAR when interfacing with Windows

2018-12-02 Thread Walter Bright via Digitalmars-d-announce
On 12/2/2018 7:39 PM, Vladimir Panteleev wrote: Could you please reply to my GitHub comments? Done.

Heads Up: Use WCHAR when interfacing with Windows

2018-12-02 Thread Walter Bright via Digitalmars-d-announce
Due to name mangling changes required by compatibility with C++11, wchar_t will no longer mangle the same as wchar. Yes, I know, argghhh. What this means for Windows API calls is that the alias for WCHAR will change from wchar to wchar_t. To get a head start on this, when you're writing

Re: D compilation is too slow and I am forking the compiler

2018-11-23 Thread Walter Bright via Digitalmars-d-announce
On 11/23/2018 5:23 AM, welkam wrote: Currently D reads the all files that are passed in command line before starting lexing/parsing, but in principle we could start lexing/parsing after first file is read. In fact we could start after first file`s first line is read. DMD used to do that. But

Re: D compilation is too slow and I am forking the compiler

2018-11-23 Thread Walter Bright via Digitalmars-d-announce
On 11/23/2018 6:37 AM, welkam wrote: Your post on reddit received more comments than D front ends inclusion to GCC. If you titled your post differently you probably wouldn't had such success so from my perspective its a net positive. Sure there are few people that took the wrong message but

Re: D compilation is too slow and I am forking the compiler

2018-11-23 Thread Walter Bright via Digitalmars-d-announce
On 11/23/2018 2:12 AM, Jacob Carlborg wrote: Would it be possible to have one string table per thread and merge them to one single shared string table before continuing with the next phase? It'd probably be even slower because one would have to rewrite all the pointers into the string table.

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
On 11/21/2018 8:48 PM, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that.

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
I neglected point out, however, that the article itself is a home run! Thank you, Vladimir!

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
On 11/21/2018 5:55 AM, Guillaume Piolat wrote: On Wednesday, 21 November 2018 at 11:18:22 UTC, Nicholas Wilson wrote: On Wednesday, 21 November 2018 at 08:07:52 UTC, Vladimir Panteleev wrote: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
On 11/21/2018 3:19 AM, Iain Buclaw wrote: On Wednesday, 21 November 2018 at 10:56:02 UTC, Walter Bright wrote: Wouldn't it be awesome to have the lexing/parsing of the imports all done in parallel? The main difficulty in getting that to work is dealing with the shared string table. What

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
On 11/21/2018 2:16 AM, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 09:46:44 UTC, Walter Bright wrote: It works by allocating memory from a memory-mapped file, which serves as the precompiled header. Hey, that's a great idea! Can we do this for DMD? :D On a more serious note:

Re: D compilation is too slow and I am forking the compiler

2018-11-21 Thread Walter Bright via Digitalmars-d-announce
On 11/21/2018 12:07 AM, Vladimir Panteleev wrote: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ I implemented precompiled headers for Digital Mars C++. It took a lng time to work all the bugs out of it. It's also a brittle system. It

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 8:37 PM, Isaac S. wrote: It probably depends on where someone is from (asinine isn't considered a big insult where I live [rural US]). Regardless of that, I will admit I did overstep (especially in calling Walter ignorant) and so I do apologize to Walter (I'm sorry that sounds

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 8:49 PM, Jonathan M Davis wrote: Not AFAIK, but calling someone or something extremely stupid or foolish is almost always a terrible idea in a professional discussion (or pretty much any discussion that you want to be civil) - especially if it can be interpreted as calling the

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 7:12 PM, Isaac S. wrote: why should an enum not convert to its declared type, rather than blindly using its literal value. Just using the literal value discards the secondary-type information the programmer had given it. D has the following match levels: 1. exact 2. conversion

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 3:50 PM, Isaac S. wrote: is asinine and ignorant. Some friendly advice - nobody is going to pay serious attention to articles that sum up with such unprofessional statements. Continuing the practice will just result in the moderators removing them.

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 3:29 PM, Rubn wrote: enum : int { a = 127 } To reiterate, this does not create an anonymous enum type. 'a' is typed as 'int'. Technically, `a` is a manifest constant of type `int` with a value of `127`. > enum A : int { a = 127 } `a` is a manifest constant of type `A` with a

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-13 Thread Walter Bright via Digitalmars-d-announce
On 11/13/2018 12:23 AM, aliak wrote: Doesn't the above miss a step, and wouldn't it be: 1) A.a => 2) A.a => So basically for the f(short) path you have 3 steps instead of 2 for the f(int) path. So does it matter how many implicit conversions need to happen before D stops trying? Or is

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Walter Bright via Digitalmars-d-announce
On 11/12/2018 1:39 PM, 12345swordy wrote: OK, I got to know what language you were using at the time, because I am curious at what other oddities does it have. I wish I could remember what it was. It was like 40 years ago :-)

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Walter Bright via Digitalmars-d-announce
On 11/12/2018 12:34 PM, Neia Neutuladh wrote: Tell me more about this "consistency". int f(short s) { return 1; } int f(int i) { return 2; } enum : int { a = 0 } enum A : int { a = 0 } pragma (msg, f(a)); // calls f(int) pragma (msg, f(A.a)); // calls f(short) I.e. it's consistent.

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Walter Bright via Digitalmars-d-announce
On 11/12/2018 11:28 AM, Adam D. Ruppe wrote: D used to have a `bit` type, wy back in the day. It was renamed to `bool` way back in D 0.148, released Feb 25, 2006. D's old bit type was not a bool. It literally was a single bit, and an array of bits was packed into an int by the compiler.

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Walter Bright via Digitalmars-d-announce
On 11/12/2018 8:28 AM, 12345swordy wrote: The issue that I see is unintended implicit conversation when passing values to functions that have both int and bool overloads. The exact same thing happens when there are both int and short overloads. The underlying issue is is bool a one bit

Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

2018-11-12 Thread Walter Bright via Digitalmars-d-announce
On 11/12/2018 2:05 AM, Jonathan M Davis wrote: *sigh* Well, I guess that's the core issue right there. A lot of us would strongly disagree with the idea that bool is an integral type and consider code that treats it as such as inviting bugs. In my college daze I was learning programming

Re: DMD backend now in D

2018-11-11 Thread Walter Bright via Digitalmars-d-announce
On 11/11/2018 3:58 PM, Mike Franklin wrote: This is a significant milestone.  Congratulations, Walter! Many people helped out with this, too. There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? tk.c fp.c os.c

DMD backend now in D

2018-11-11 Thread Walter Bright via Digitalmars-d-announce
As: https://github.com/dlang/dmd/pull/8946 removes the header files for the old C++ code!

Re: Backend nearly entirely converted to D

2018-11-08 Thread Walter Bright via Digitalmars-d-announce
On 11/8/2018 9:23 AM, welkam wrote: And where can i read about naming convention? My guess its not documented anywhere and would not be in foreseeable future or ever. Also are you sure you are not talking about two letter variables like sc for scope fd for function declaration td for template

Re: Profiling DMD's Compilation Time with dmdprof

2018-11-08 Thread Walter Bright via Digitalmars-d-announce
On 11/7/2018 11:41 PM, Manu wrote: I'm on an i7 with 8 threads and plenty of ram... although threads are useless, since DMD only uses one ;) So does every other compiler. To do a multicore build, you'll need to use a makefile that supports -j.

Re: Profiling DMD's Compilation Time with dmdprof

2018-11-08 Thread Walter Bright via Digitalmars-d-announce
On 11/7/2018 10:08 PM, Vladimir Panteleev wrote: It does seem to take more time now; I wonder why. That's easy. It's because nobody has profiled it for years. Another reason is the backend being in D now, it is being compiled with DMD rather than gcc/clang.

Re: Backend nearly entirely converted to D

2018-11-07 Thread Walter Bright via Digitalmars-d-announce
Slides and video link: http://nwcpp.org/october-2018.html On 11/7/2018 2:08 PM, H. S. Teoh wrote: I don't speak for the compiler devs, but IMO, one-letter variables are OK if they are local, and cover a relatively small scope. Java-style verbosity IMO makes code *harder* to read because the

Re: Backend nearly entirely converted to D

2018-11-07 Thread Walter Bright via Digitalmars-d-announce
On 11/7/2018 1:49 PM, welkam wrote: One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change? Sorry, it would not be welcome. Single

  1   2   3   4   5   6   7   8   >