Re: What do you want to see for a mature DLang?
On 12/30/2017 11:23 PM, IM wrote: While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs? Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it. Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.
Re: What do you want to see for a mature DLang?
On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote: On 12/30/2017 6:42 AM, Muld wrote: In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood. Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out. While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?
Re: What do you want to see for a mature DLang?
On 12/30/2017 6:42 AM, Muld wrote: In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood. Anyone can contribute to bugzilla with reasoned advice about what to do with various issues, and can review PRs. The people responsible are, well, anyone who wants to be. Please join and help out.
Re: Lazily parse a JSON text file using stdx.data.json?
Am Sun, 17 Dec 2017 10:21:33 -0700 schrieb David Gileadi : > On 12/17/17 3:28 AM, WebFreak001 wrote: > > On Sunday, 17 December 2017 at 04:34:22 UTC, David Gileadi wrote: > > uh I don't know about stdx.data.json but if you didn't manage to succeed > > yet, I know that asdf[1] works really well with streaming json. There is > > also an example how it works. > > > > [1]: http://asdf.dub.pm > > Thanks, reading the whole file into memory worked fine. However, asdf > looks really cool. I'll definitely look into next time I need to deal > with JSON. There is also the JSON parser from https://github.com/mleise/fast if you need to parse 2x faster than RapidJSON ;) -- Marco
Re: What do you want to see for a mature DLang?
On Sunday, 31 December 2017 at 02:06:03 UTC, Iain Buclaw wrote: 2. Feel free to look at the list of regressons. https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=--- "This list is too long for Bugzilla's little mind" Mmm..just imagine how our human mind reacts then ;-) But... as you point out...some 'filtering' makes it 'seem' a little less daunting ;-)
Re: What do you want to see for a mature DLang?
On 31 December 2017 at 02:07, codephantom via Digitalmars-d wrote: > On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote: >> >> >> All open issues are actionable, and require some action. They are not >> noise, and many issues whose fix requires a change in language specification >> or semantics are understandably left to the few who have the authoritative >> to make such final decisions on whether it should be accepted or rejected. >> >> Age of issue is not a big deal. In fact I see it as a good sign that at >> least issues are left to breathe while we wait and understand the impact or >> urgency of it. As opposed to jumping in and fixing issues immediately >> without taking due diligence on the wider picture it affects. > > > Is this a problem with triage? > > i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty > triaging. > > How does a contributor prioritise their contribution to items in bugzilla? > Either: 1. By picking up an issue that you have a vested interest in seeing fixed. 2. Feel free to look at the list of regressons. https://issues.dlang.org/buglist.cgi?bug_severity=regression&component=dmd&list_id=218477&query_format=advanced&resolution=--- Bigger projects or features are delegated between the core maintainers, or if a champion comes to take the reigns, then they have the freedom to go ahead. For everything else, it is pretty much a free-for-all in terms of what you want to get fixed. Almost nobody is being paid to contribute to the language here.
Re: What do you want to see for a mature DLang?
On 12/30/2017 04:07 AM, IM wrote: I like what the D foundation did to the website, the language and library docs, the Learn section, the forums, the resources ... etc. That definitely gives the impression of maturity. As far as I'm aware, the foundation isn't too active in those areas; unless Vladimir or Seb are on their payroll now. Maybe the foundation pays the electricity bills, but the work is done by volunteers.
Re: D as a betterC a game changer ?
On Saturday, 30 December 2017 at 21:40:29 UTC, Adam Wilson wrote: This is not true. I was at DConf one year (can't remember which) and I watched the representative of one of D's larger corporate users do everything but actually get on his knees and beg Walter to make a breaking change. IIRC they demonstrated their work around for the missing change a couple of DConf's later. Are you referring to this: https://www.youtube.com/watch?v=DinkkD6Pt34 We don't all need to be that "ruthless with memory efficiency" ( e.g.I have 24GB of memory on my desktop pc! GC kicks in at what...20MB??) But some really good points were made nonetheless, and I enjoyed the perspective he offered. Let's fix the crap we have now. It'll take a while, it's not sexy, and it certainly won't make headlines on HN or Reddit. But it will have the effect of combating the biggest negative that D has to adoption. The perception of instability. A little overstated perhaps.. I certainly would not be using the word 'crap' or 'instability' describe the current state of D. But D could benefit from some focused tender love, and care ;-)
Re: What do you want to see for a mature DLang?
On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote: All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects. Is this a problem with triage? i.e. like a hositpital emergency ward chaos rules, cause nobody is on duty triaging. How does a contributor prioritise their contribution to items in bugzilla? Or is it perhaps a tooling problem? (i.e. bugzilla lacks features that are needed). Or is it a problem with not having enough people on duty, triaging? Or is it a problem with just too many patients coming in? Or .. ??
Re: D as a betterC a game changer ?
On 12/30/2017 3:47 PM, rjframe wrote: He does have a point. At work, people often email me directly, or stop me in the hallway, to report things that belong on the issue tracker. I consistently tell people that if I don't fix something the same day, it likely isn't going to happen unless it's on the issue tracker, yet again and again they'll tell me of a problem in person, quite often when I've left my organizer in my office. There is an official method of dealing with bugs, so that needs to be the system used, and consistently used. If the current system is insufficient, it should be improved or replaced, but you can't run reports from IRC or the NG. You're exactly right. Before Brad Roberts set up bugzilla, the bug reporting system was an email folder on my system. Such a thing does not scale, was completely disorganized and erratic, was not accessible by anyone but me, etc. Having a centralized, organized, professional bug reporting system is the *only* practical way of managing bug reports, discussions about them, status, statistics, and resolutions. Verbal reports, emails, forum postings, chat logs, reddit, etc., is completely impractical as a bug reporting system once a project exceeds a certain size, and D exceeded that threshold a long, long time ago. While filing a bugzilla issue does not guarantee action, not filing an issue pretty much guarantees no action.
Re: D as a betterC a game changer ?
On 12/30/2017 3:04 PM, Nicholas Wilson wrote: I can hear him already, "Post it on buzzkill or it won't get fixed!" It's already on bugzilla, and was already fixed.
Re: D as a betterC a game changer ?
On Sat, 30 Dec 2017 23:04:21 +, Nicholas Wilson wrote: > I can hear him already, "Post it on buzzkill or it won't get fixed!" He does have a point. At work, people often email me directly, or stop me in the hallway, to report things that belong on the issue tracker. I consistently tell people that if I don't fix something the same day, it likely isn't going to happen unless it's on the issue tracker, yet again and again they'll tell me of a problem in person, quite often when I've left my organizer in my office. There is an official method of dealing with bugs, so that needs to be the system used, and consistently used. If the current system is insufficient, it should be improved or replaced, but you can't run reports from IRC or the NG.
Re: D as a betterC a game changer ?
On Saturday, 30 December 2017 at 23:04:21 UTC, Nicholas Wilson wrote: I can hear him already, "Post it on buzzkill or it won't get fixed!" Stupid autocorrect. Bugzilla.
Re: D as a betterC a game changer ?
On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
Hi Walter, Can you take a look at this betterC bug:
https://issues.dlang.org/show_bug.cgi?id=18099
==
struct D()
{
struct V {
~this() {
}
}
auto get() {
V v ;
return v ;
}
}
alias T = D!();
Error: Cannot use throw statements with -betterC
a.d(12): Error: template instance a.D!() error instantiating
It is a block for implement auto RefCount in betterC. Since
there is no GC, auto RefCount is the way to make D work far
more useable then pure C, and it relay on this bug to be fixed.
I can hear him already, "Post it on buzzkill or it won't get
fixed!"
Re: D as a betterC a game changer ?
On 12/27/17 00:10, Pawn wrote: On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom wrote: IMHO..What will help the cause, in terms of keeping D as a 'modern' programming language, is the willingness of its designers and its community to make and embrace 'breaking changes' ... for example, making @safe the default, instead of @system. It's been expressed that there are now too many codebases such that introducing "breaking changes" would upset many people and companies. D is a mature language, not a young one. This is not true. I was at DConf one year (can't remember which) and I watched the representative of one of D's larger corporate users do everything but actually get on his knees and beg Walter to make a breaking change. IIRC they demonstrated their work around for the missing change a couple of DConf's later. The reason that D isn't making breaking changes is that the language has enough broken stuff as it is. It does not make much sense to fork a code-base with significant known issues, break more things without fixing the existing things, and then release as a new version. It would create even more bugs and perpetuate the 'D is broken' meme. Once D2 has been thoroughly vetted and is free of known-bugs (sometimes called Zero Bug Bounce, there may be unknown bugs that are discovered, but all known bugs are fixed). Additionally, consider that if we have a stable base in D2 it will be much easier to merge bug-fixes into D3 while D3 is being worked on. Let's fix the crap we have now. It'll take a while, it's not sexy, and it certainly won't make headlines on HN or Reddit. But it will have the effect of combating the biggest negative that D has to adoption. The perception of instability. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Maybe D is right about GC after all !
On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright wrote: On 12/22/2017 7:23 AM, Russel Winder wrote: I think we are now in a world where Rust is the zero cost abstraction language to replace C and C++, except for those who are determined to stay with C++ and evolve it. Maybe it is. But that is not because D isn't up to the task. I've converted a large program from C to D (Digital Mars C++'s front end) with -betterC and it really is a zero cost abstraction. The memory safety benefits are there (DIP 1000), RAII is there, nested functions, array bounds checking, template metaprogramming, CTFE, etc. D as betterC really is a game changer, for anyone who cares to give it a try. I think D's great strength compared to Rust is that it is much easier to code in D. How easy is it write a simple linked list in Rust - without using library features? Rust makes even simple tasks hard to write. D as a language combines best features of C, C++ and Java which is great in my view. And the better C option makes it really viable for creating shared libraries that can be easily used in other projects. Trying to replace C is really not the right goal for D I think. In my experience, C and C++ have already been replaced by Java, C# or Go in application development except where the code is legacy and is just being kept "alive". And nothing beats C for systems developers who want a high level assembler rather than abstractions and safety features. In my view, D should be D - the main issue with D is not the language, but the tooling. It needs to "just work" on the major platforms and needs good IDE support. Regards Dibyendu
Re: D as a betterC a game changer ?
On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder wrote: And is the way every programmer learns their non-first language. All newly learned programming languages are merged into a person's "head language" which is based on their first language but then evolves as new languages, especially of new computational mode, are learned. See Marian Petre and others work over the last 30 years for scientific evidence of this. Hm… I have some problem with this. I can see how it would apply to Algol-like languages, but for I don't see how it fits on very different concepts like SQL/datalog/prolog, scheme, machine language, OO etc… There might be some empirical issues here as _most_ programmers would move to something similar, but statistical significance doesn't imply causality…
Re: Maybe D is right about GC after all !
On Sunday, 24 December 2017 at 16:51:45 UTC, Patrick Schluter wrote: That's the biggest problem with C++, they pile on relentlessly half baked feature after half baked feature in a big dump that no one with a life can ever grasp. I think D has more first class language features (and thus special casing) than C++. For instance, C++ lambdas are just sugar over objects and most of the new stuff is primarily library features with some minor language tweaks to back it. So I don't think the core C++ language itself has changed dramatically. Like, constexpr is mostly about allowing things that were forbidden, but it is opening new ways to structure code, which in turn "deprecates" some old clumsy idioms… Except those old clumsy idioms linger… both in online tutorials, in code bases and of course in the mentality of the programmers… Since those "deprecated" idioms are built by combining features it cannot easily be detected and transformed into "modern" idioms by a tool either. Whereas a high level dedicated language feature could more easily be "deprecated" and dealt with in a language upgrade. Which is one downside of using library-based constructs over language constructs. So I am a bit torn on library vs language features. From an aesthetics point of view having a small and expressive language seems like the better choice, but one can make good arguments for a low level oriented DSL as well. With a well designed DSL the compiler author might more easily reason about the programmers intent and perhaps make better optimization choices… thus allowing the programmer to write more readable performant code… I think the DSL approach makes more sense as computer architecture get less simplistic. Although currently CPU vendors target C-like code, that might change in the future as less code is written in C-like languages…
Developing blockchain software with D, not C++
In this video[1] from 2016, developer talks about C++ memory safety features, meta-programming, maturity and few others as main reasons they choose it for developing their blockchain software (the way I got it from a quick view). Besides, D maturity (which I can't confirm or deny), what else does D miss to be considered a better alternative for blockchain in 2018? D is also more productive, has safety and unittest built-in. 1. https://www.youtube.com/watch?v=w4jq4frE5v4
Re: Maybe D is right about GC after all !
On Thursday, 28 December 2017 at 16:43:41 UTC, John Gabriele wrote: On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote: On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder wrote: On Wed, 2017-12-27 at 18:41 +, Laeeth Isharc via Digitalmars-d wrote: […] However the GStreamer folk are backing Rust (for memory safety issues noted earlier) so even though D has a GStreamer binding (thanks to Mike and GtkD) I more or less have to use Rust because it is the official binding. Comparing and contrasting D and Rust is interesting for me. Both have many pluses and many minuses. However, in the end, the GStreamer core people know C, C++ a bit, D not at all. I suspect even if the choice had been Rust or D, Rust would have been chosen because it has no GC and D is a GC language. Not only GStreamer, Rust is on its way to become an offical GNOME language, and who knows, eventually take over Vala's role. I haven't followed Gnome+Rust news. What suggests Rust may be on its way to become an official Gnome language? GNOME and Rust devs are collaborating on how to easily integrate Rust with the Gtk+ object model. Meetings were held at GUADEC, and a few projects, like GStreamer are now only using Rust for new code being written. It remains open what they will do with existing plugins. The blog reports about those meetings are quite easy to find. For example, https://2017.guadec.org/talks-and-events/index.html#abstract-5-replacing_c_library_code_with_rust_what_i_learned https://internals.rust-lang.org/t/rust-and-gnome-meeting-notes/4339
Re: What do you want to see for a mature DLang?
On 30 December 2017 at 15:42, Muld via Digitalmars-d wrote: > On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote: >> >> It's not like we have a shortage of bugzilla issues and are wondering what >> to do next. > > > Yah there are a ton of Bugzilla issues, that's the problem. More than half > of them aren't "actionable" as you put it. > There's nothing unmanageable about the issue tracker, nor are the number of open bugs even a reliable measure of anything. For instance, Python has more than twice as many open bugs than D. > Here's the problem, look at something like Rust: > > Pull requests? 95 open, it's about the same as Dlang, But if you go to the > last page... > > https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen > > Look at that the oldest one is from October 15th, 20_17_. > > Now we go to DMD... > > https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen > > Oldest one is from January 17, 20_13_. > Hey, I take offence to that. https://issues.dlang.org/show_bug.cgi?id=17839 https://github.com/dlang/dmd/pull/7503 https://github.com/dlang/dmd/pull/7508 https://github.com/dlang/dmd/pull/7509 https://github.com/dlang/dmd/pull/7510 https://github.com/dlang/dmd/pull/7527 https://github.com/dlang/dmd/pull/7536 And many more closed that were even older, and I'm not the only one reviving these patches, all of which are either abandoned, incomplete, or too controversial (there is always a valid reason why open PRs were left to rot). > > In contrast this same problem exists for Bugzilla. You say it's working > cause it's better than using notepad or some other stupid shit. Bugzilla > isn't the issue, it's the fact the people maintaining it aren't willing to > commit to anything and leave issues open that shouldn't be left open. That > just results in noise making it difficult to see what actual issues are. I'm > not even talking about duplicate entries as you seem to have have > misunderstood. All open issues are actionable, and require some action. They are not noise, and many issues whose fix requires a change in language specification or semantics are understandably left to the few who have the authoritative to make such final decisions on whether it should be accepted or rejected. Age of issue is not a big deal. In fact I see it as a good sign that at least issues are left to breathe while we wait and understand the impact or urgency of it. As opposed to jumping in and fixing issues immediately without taking due diligence on the wider picture it affects.
Re: What do you want to see for a mature DLang?
On Saturday, 30 December 2017 at 06:55:13 UTC, Walter Bright wrote: It's not like we have a shortage of bugzilla issues and are wondering what to do next. Yah there are a ton of Bugzilla issues, that's the problem. More than half of them aren't "actionable" as you put it. Here's the problem, look at something like Rust: Pull requests? 95 open, it's about the same as Dlang, But if you go to the last page... https://github.com/rust-lang/rust/pulls?page=4&q=is%3Apr+is%3Aopen Look at that the oldest one is from October 15th, 20_17_. Now we go to DMD... https://github.com/dlang/dmd/pulls?page=6&q=is%3Apr+is%3Aopen Oldest one is from January 17, 20_13_. In contrast this same problem exists for Bugzilla. You say it's working cause it's better than using notepad or some other stupid shit. Bugzilla isn't the issue, it's the fact the people maintaining it aren't willing to commit to anything and leave issues open that shouldn't be left open. That just results in noise making it difficult to see what actual issues are. I'm not even talking about duplicate entries as you seem to have have misunderstood.
Re: What do you want to see for a mature DLang?
On Friday, 29 December 2017 at 23:27:38 UTC, Walter Bright wrote: On 12/29/2017 3:15 PM, Muld wrote: Bugzilla is a huge mess tbh, creating a request in bugzilla won't lead anywhere. Fixes for bugzilla issues are posted on github nearly every day. This does not mean anything, just cause fixes for Bugzilla issues are being fixed "nearly every day" is not part of the larger problem. The people that are pushing fixes for those issues tend to be the same people that are creating them. Sure I can create a bugzilla issue, but unless I'm the one that creates a fix for it, it probably won't be fixed unless it is a regression. It's so bad honestly it'd probably be less work just to create a new bugzilla and port any relevant entries from the current one. It's not a big deal to create a duplicate of existing entries. As to bugzilla itself, despite its issues, it is far far far better and more organized than randomly looking in chat rooms, stack overflow, newsgroups, etc. Living on Mars is far far better than trying to live on the surface of the Sun. Just cause that's the case doesn't mean you should stop looking for a place called Earth.
Is there a way to call scope guard without throw exception?
I try to find a way to yield custom fiber without throw exception, is it possible ? I need make sure the scope guard is executed and the resource will auto release relay on scope(exit). After fiber yield, the spoke guard is not able to execute, unless I throw a exception in Fiber. I am look if there is some hack method to make the fiber Interrupted at any time with scope(exit) code executed.
Re: TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not TypeInfo_Interface?
On 12/27/17 6:28 PM, Tofu Ninja wrote:
On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
I didn't get any response in learn for this so I will ask it here.
TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not
TypeInfo_Interface?
Is this correct? Or is it a bug?
Doesn't make much sense to me.
Also the following code prints false so there are some consequences to
this.
# #
import std.stdio;
void main(string[] args) {
writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // false
}
interface i {}
class c : i {}
What is the proper way to handle this mismatch?
Is this mismatch intended or just some implementation detail?
Peoples thoughts on this?
I guess I will just not get an answer to this, seems like just some
weirdness of D that will just stick there. The typeinfo system seems
really half baked and really provides very little in terms of usefulness.
I'm not even sure why TypeInfo_Interface exists. It seems to be a thin
wrapper over its TypeInfo_Class member `info`. TypeInfo_Class itself has
an overridable `info` member which is never overridden, so I'm not sure
what the purpose of that is either.
Looking at the implementation of TypeInfo_Interface, it appears that the
only reason to have it, is to allow using interfaces as hash keys. But
the blunt casting there, I don't think is right. Not all interfaces can
be cast to Object.
I'll note that opEquals is also implemented incorrectly.
IMO, TypeInfo_Interface should be derived from TypeInfo_Class, and
simply override the equals/getHash/compare functions. Then change the
type of 'classinfo' inside the Interface struct to TypeInfo_Interface.
The compiler needs to be updated for this of course.
So in short, I think there are bugs here, but probably not what you
expected.
-Steve
Re: What do you want to see for a mature DLang?
On Friday, 29 December 2017 at 07:53:51 UTC, IM wrote: I will start: -- Better compiler errors, better compiler errors, better compiler errors. I really wish that the compiler errors could receive some refinement. Mostly it feels like some error text just being thrown at me. It needs to be better formatted, more helpful, with suggestions about how to fix (if possible). To illustrate my point: - See the compile errors I've just encountered with DMD: https://cdn.pbrd.co/images/H0q609l.png - Now compare that with an error produced by rustc: https://cdn.pbrd.co/images/H0q6bLi.png Simple things like these make a big difference. D Lang has been around for a long while now, and hence signs of its maturity has to show everywhere, especially in the compiler, as well as the package manager. * R-value references. * More "Hands free" package/dependency management (See Cargo(Rust)) * GC dependency free stdlib, with built-in general purpose async i/o library * More sophisticated, official language server * Better IDE support * Full-fledged smart pointer (resembling std::unique_ptr, std::shared_ptr, std::weak_ptr in the standard * Riddance of `object`, and being able to hand-make rootobject. No common root class.
Re: What do you want to see for a mature DLang?
On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing wrote: On Friday, 29 December 2017 at 09:46:05 UTC, JN wrote: AFAIK Rust doesn't have templates, but generics. Generics usually have much cleaner error messages because they are mostly used for generic functions and classes, meanwhile templates can do that too but much, much more, but when they break, you get entire paragraphs of template errors. Templates are bad because they write code for you. And it's that code you don't write that could have errors. It's a double edge sword. Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc... Yes, it's the same issue in C when using complicated macros. You have to do all substitutions by hand to understand the real error message. D templates have more information so there's hope to get a better resolution of the error cause. But, the error message thing is a double edge sword, the more information is given the more difficult it gets to quickly find what the issue is. Again to illustrate with my C experience (sorry I'm paid for programming C, D is hobby that I try to sneakily introduce). The gcc 4 error messages were simple 1 lines errors, from gcc 5 on they introduced the multi-line errors with positioning like in that Rust example above. At the beginning I was quite happy with that as the error messages are so much more detailed, but now after some time, I find them really annoying as it is much more eye straining to find the real error message in between the positioning text.
Re: What do you want to see for a mature DLang?
On Saturday, 30 December 2017 at 07:30:39 UTC, Elronnd wrote: On Friday, 29 December 2017 at 22:05:31 UTC, I Love Stuffing wrote: Also, for a mature D, some damn collections. Queues, Stacks, Deques, etc... std.container.dlist (https://dlang.org/phobos/std_container_dlist.html)? The queue or stack usage is not obvious at all. One would expect something like stack.push, stack.pop or queue.enque, queue.deque and may be a peek(). Instead one will get 33 functions that can be used with a doubly-linked list.
