Re: Compare boost::hana to D
On Friday, 21 April 2017 at 13:10:43 UTC, Adam D. Ruppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html BTW in your D foreach, you could also have done `switch` void trigger(string event) { switch(event) { foreach (i, e; events) { case e: foreach (c; callbacks_[i]) c(); return; } default: assert(false, "trying to trigger an unknown event: " ~ event); } } And the compiler+runtime can optimize that into a binary search when it gets larger automatically. Doesn't the latest compiler complain with a depreciation that i/e initialization is being skipped?
Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT
On Sunday, 23 April 2017 at 02:45:09 UTC, evilrat wrote: On Saturday, 22 April 2017 at 10:38:45 UTC, Stefan Koch wrote: On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: [...] If you could share the code it would be appreciated. If you cannot share it publicly come in irc sometime. I am Uplink|DMD there. Sorry, I failed, that was actually caused by build system and added dependencies(which is compiled every time no matter what, hence the slowdown). Testing overloaded functions vs template shows no significant difference in build times. Ah I see. 4x slowdown for 10 instances seemed rather unusual. Though doubtlessly possible.
Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT
On Saturday, 22 April 2017 at 10:38:45 UTC, Stefan Koch wrote: On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: Is this apply to templates too? I recently tried some code, and templated version with about 10 instantiations for 4-5 types increased compile time from about 1 sec up to 4! The template itself was staightforward, just had a bunch of static if-else-else for types special cases. If you could share the code it would be appreciated. If you cannot share it publicly come in irc sometime. I am Uplink|DMD there. Sorry, I failed, that was actually caused by build system and added dependencies(which is compiled every time no matter what, hence the slowdown). Testing overloaded functions vs template shows no significant difference in build times.
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 12:16:19 UTC, Nordlöw wrote: On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote: If I get this to work, I'm gonna try pushing it into std.conv. Another bit to pick on is the return value. auto x = toWithDefault!int("1", 0.0f); typeof(x) will be float even though the caller requested a conversion to int. Probably should be T toWithDefault(T,S,U)(S v, /*lazy*/ U defaultValue) if (is(typeof(() { T r = defaultValue; }))) { //... }
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 18:26:56 UTC, Dmitry Olshansky wrote: On 4/22/17 6:57 PM, Stanislav Blinov wrote: On Saturday, 22 April 2017 at 16:41:00 UTC, Nordlöw wrote: If defaultValue is not lazy, it's potentially wasteful. What do you mean with "potentially wasteful"? Excess calls to copy constructors? Evaluation of an expression the result of which might not be used. defaultValue could be anything: a literal, an lvalue, a result of a function call... IMO you are overenginering this. defaultValue will most likely be something distinct such as compile-time constant. I'm looking at it from the perspective of it being added to Phobos, which seems to be Nordlöw's intent. There should not be any assumptions in that scenario, or there should be an overload for the "most likely" case. The signature says: defaultValue will be anything convertible to typeof(defaultValue), and is going to be evaluated regardless of whether or not std.conv.to() call throws. All I'm saying is the purpose *suggests* that the defaultValue parameter should be lazy, and that that currently annotating it so defeats that purpose is due to a bug. Although one could work around the bug for the time being by using std.exception.assumeWontThrow.
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: DIP 1005 is titled "Dependency-Carrying Declarations". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion. An extensive discussion regarding this DIP has already taken place [1]. Thanks in advance to all who participate. Destroy! [1] http://forum.dlang.org/thread/o2psvk$1m96$1...@digitalmars.com?page=1 I thought this DIP was invalidated by the self-important workaround? http://forum.dlang.org/post/o72kq8$ggc$1...@digitalmars.com https://github.com/dlang/druntime/pull/1756#issuecomment-277463742 Why is this still up for review?
Re: Default-valued nothrow @nogc std.conv:to
On 4/22/17 6:57 PM, Stanislav Blinov wrote: On Saturday, 22 April 2017 at 16:41:00 UTC, Nordlöw wrote: If defaultValue is not lazy, it's potentially wasteful. What do you mean with "potentially wasteful"? Excess calls to copy constructors? Evaluation of an expression the result of which might not be used. defaultValue could be anything: a literal, an lvalue, a result of a function call... IMO you are overenginering this. defaultValue will most likely be something distinct such as compile-time constant. --- Dmitry Olshansky
Re: 2.074.0-regression in move semantics
On Saturday, 22 April 2017 at 11:54:12 UTC, Nordlöw wrote: can no longer move the expression `y`. I don't understand why this specific case fails when others in the standard library apparently hasn't. Help, please. Please file a regression at issues.dlang.org and prefix the subject with "[Reg 2.074.0]".
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 17:37:13 UTC, Vasudev Ram wrote: I actually worked years ago, for a while, on a legacy banking software product written in C In fact, that one was in Microsoft C for DOS 3.0 ... !!! :) I actually also worked some years later on another product in C, which had some similar issues (but turned out quite well in the end, after I got involved with it as the team leader), but that was on Windows, and is another story, maybe will tell it some time later ...
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 08:33:04 UTC, Russel Winder wrote: On Fri, 2017-04-21 at 21:20 -0700, Jonathan M Davis via Digitalmars-d wrote: […] I've never heard of anyone doing anything like this in any language. Normally, you'd just say that someone is a D programmer or a C++ programmer or a Java Programmer, etc. But then again, I come from a C++ background, not a scripting language background, and the folks who primarily use scripting languages often tend to look at things differently. I guess most people using scripting languages are just Bashing things together. ;-) Awk! What you sed? ;) just Bashing things together Nice joke, but not necessarily true in reality. There could be people writing good solid code in scripting languages and the reverse in compiled ones too - in fact I've seen code of some very poor (in quality and knowledge) C developers, who know very little of the ins and outs of the language (pointers and memory management in particular, but other areas too). That's one of the reasons why we have so many buffer overflows and exploits, though of course, I acknowledge, it's not easy to write perfect C code that does not have those issues. I actually worked years ago, for a while, on a legacy banking software product written in C - in maintenance mode - after almost all the original developer team had left the company. Saw some really bad code. Variables like zzy123 were the least of it ... Not a reflection on the language at all, only on those developers.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: On Fri, 2017-04-21 at 17:20 +, Vasudev Ram via Digitalmars-d wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. I would hope none of these, but as ketmar said "programmer". See my reply to Jonathan M Davis, above. Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. I think you are over-generalizing, and don't fully agree. Definitely, some people may use those terms in that manner and for that reason. Boo to them :) I'm never in favor of such pressuring, exclusion or whatever. And BTW I know what I am talking about, having seen some of it in real life, one example being in the Ruby world. I did Ruby commercially for a while, learned it even before Rails was created or became popular. And I frequented the Ruby message boards and blogs for a while, and participated in them. Saw a lot of what you describe, others have written about it too. A good amount ofjuvenile and one-up-manship behavior. That is one reason why I moved to Python (apart from liking it after using it some). The community tended to me more mature and engineering-oriented, rather than like the Ruby people, many of whom were hackish and gloated over having done some cool stuff with Ruby "magic" or monkey-patching (which often results in hard-to-find bugs - cool for experimenting, bad for production use). As far as being polyglot is concerned, I'm quite in favor of that too, and would never dream of even suggesting, let alone pressuring, people to "eschew all other languages", as you put it (this is the point about which I don't agree and think you are over-generalizing). In fact, I do training too, and once, a student who was taking a Python course from me, was talking about his goals (he works in another field and is trying to get into development). As part of that, he mentioned wanting "to become a good programmer (Python)" - at which point I immediately replied to him, that his goal should not be to become a good _Python_ programmer, per se, but to become a good _programmer_, period, because there is much more to programming than one or even many languages - databases, use of libraries, software design, testing, debugging, use of source control and other tools, naming conventions, other programming conventions and style, etc. Mentioned books like Code Complete to him - as a great resource on those lines. And I'm a polyglot programmer myself, having worked on BASIC (learnt on home computers), Pascal, C, Java, Informix 4GL. Done real commercial work in all of those, apart from the same in both Ruby and Python. And even keep dabbling in new languages now and then. That's how I came across D, for example, which I like a lot - IIRC it was by reading some article in a computer magazine, could have been Dr. Dobbs. A good programmer can work professionally with a number of languages, the psychology of programming people have data supporting this theory – if the languages have different computational models. Totally agreed. Thus I would claim to be a programmer currently working with D for the project I am working on just now, with SCons/Python for the build system. In a while it will be C++ on another project with CMake. Later still it will be C and Meson on a different project. Further on it will be Kotlin and Frege using Gradle for yet another project. Same here. Language agnostic. It's the best way. Another anecdote - once, in a company where I worked and was managing a product team, I had a need to write a small reminder utility for my own use. The project was in C++ and Java (I worked on the Java side), but since I knew Python and it was a good fit for the tool, I did it in Python - in a few minutes. One of my team members wanted to do it too, so, since he only knew Java, when I told him I was doing it in Python and it would be done very fast, he smiled and said "I'll do it in Java" - and proceeded take more time than I did for the same functionality. Nor was there any performance or other requirement that necessitated Java - he did it because it was the only language he knew. "Use the right tool for the job" and all that ...
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 16:14:29 UTC, Timon Gehr wrote: Please reconsider. This is new syntax. It looks like old syntax but behaves differently. I suppose the biggest issue is: - module mod; import std.stdio; struct A { ~this ( ) { writeln("dtor"); } } - - module test; class C { with (import mod) A a; // declaration, lives as long as C lives void test ( ) { with (import mod) // statement { A a; // destroyed on exit of scope } // a was destroyed, and is not even visible here } } - I can see how this can be a pain point. If it's a big worry then I'd be ok with using one of the syntactic alternatives, like 'import (std.stdio);'.
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 16:41:00 UTC, Nordlöw wrote: If defaultValue is not lazy, it's potentially wasteful. What do you mean with "potentially wasteful"? Excess calls to copy constructors? Evaluation of an expression the result of which might not be used. defaultValue could be anything: a literal, an lvalue, a result of a function call...
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Saturday, 22 April 2017 at 04:20:40 UTC, Jonathan M Davis wrote: On Friday, April 21, 2017 17:20:14 Vasudev Ram via Digitalmars-d wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. Interested to know, just for fun ... I do realize that there may not be commonly known or accepted terms like this for all languages. For example, I don't know if there is such a term for a C or C++ developer. Might make for an interesting thread. I've never heard of anyone doing anything like this in any language. Normally, you'd just say that someone is a D programmer or a C++ programmer or a Java Programmer, etc. But then again, I come from a C++ background, not a scripting language background, and the folks who primarily use scripting languages often tend to look at things differently. - Jonathan M Davis I gave the examples of the terms Pythonista and Rubyist right in the message subject. You personally might not have heard of them or similar ones, as you say. But others have. Those terms are used somewhat widely [1] - "Pythonista" is often by Python programmers to refer to themselves (sometimes Pythoneer is used), and "Rubyist" is often used by Ruby programmers to refer to themselves (individually or collectively, as in, "I'm a Pythonista" (sometimes seen on blogs' About pages or Twitter or LinkedIn bios) or "(us/as) Pythonistas" and other variations of the same. Ditto for Rubyists. Another example I've seen used is Lisper (and Lisp is both a compiled and interpreted language - so it's not like such a term is restricted only to scripting or interpreted languages). [1] Using the word "widely" anecdotally, of course - obviously I've not done a survey on something as trivial as this - it's just that I've been in the field for quite a while, working, interacting with people, reading forums, etc. - and have noticed it used quite often. And I've used Ruby for a few years and Python for many years now, both of them in commercial projects, Python in commercial training that I give, as well as for my own personal projects (mainly Python only). Secondly, using those terms does not mean they are formal designations of any kind. They are just casual terms that someone must have initially made up and that others caught on to and started using, to describe themselves and their community - i.e. Python or Ruby _users_, not all of whom are necessarily users of those languages _alone. Plenty of Python and Ruby developers use other languages too, including compiled / statically typed ones, like C, C++, Java, etc. I am one of them, in fact - I've used both C (and on DOS, Windows and Unix, a lot) and Pascal (Turbo Pascal a lot, Delphi some) earlier, Java some too. (See my other reply upcoming after this one - to Russel Winder). In general, those terms are not meant to be either pejorative or the reverse of pejorative, although some people may of course use the terms disparagingly, self-glorifyingly or whatever. But then again, I come from a C++ background, not a scripting language background, and the folks who primarily use scripting languages often tend to look at things differently. Yes, if a person comes from only (either) one of those backgrounds - then they are more likely to look at things differently. But there are lots of people who have backgrounds in both (scripting/interpreted and compiled), and some have a lot of background in both, too.
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 15:36:56 UTC, Stanislav Blinov wrote: On Saturday, 22 April 2017 at 12:16:19 UTC, Nordlöw wrote: On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote: Is there any way I can make it `@nogc` without having to modify the code in `std.conv`? If I get this to work, I'm gonna try pushing it into std.conv. If defaultValue is not lazy, it's potentially wasteful. What do you mean with "potentially wasteful"? Excess calls to copy constructors?
Re: DIP 1005 - Preliminary Review Round 1
On 22.04.2017 18:25, Stefan Koch wrote: On Saturday, 22 April 2017 at 16:13:20 UTC, Timon Gehr wrote: This is how it works for static if, and it is also how it will work for static foreach, so it is even consistent with other language features. So you will touch up your static foreach DIP ? If so I am okay with building the implementation. Sounds good. Let's discuss this at DConf.
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 16:13:20 UTC, Timon Gehr wrote: This is how it works for static if, and it is also how it will work for static foreach, so it is even consistent with other language features. So you will touch up your static foreach DIP ? If so I am okay with building the implementation.
Re: DIP 1005 - Preliminary Review Round 1
On 22.04.2017 18:17, Timon Gehr wrote: On 22.04.2017 17:16, Andrej Mitrovic wrote: On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md with (Type) and with (TemplateInstance) are always declarations and do not introduce a new scope. Does that mean we can now do things like this?: - module m; struct A { struct B { } } with (A) B b; - That's a pretty cool addition. With the current wording of the DIP, this will not work in local scopes. Why do we need more features for declaring global variables? Correction: It will not work in function scopes.
Re: DIP 1005 - Preliminary Review Round 1
On 22.04.2017 17:16, Andrej Mitrovic wrote: On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md with (Type) and with (TemplateInstance) are always declarations and do not introduce a new scope. Does that mean we can now do things like this?: - module m; struct A { struct B { } } with (A) B b; - That's a pretty cool addition. With the current wording of the DIP, this will not work in local scopes. Why do we need more features for declaring global variables?
Re: DIP 1005 - Preliminary Review Round 1
On 22.04.2017 17:31, Andrej Mitrovic wrote: On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md Very solid DIP! And I like the use of `with` and it's proposed extension to be allowed in declarations, rather than introducing new syntax. Please reconsider. This is new syntax. It looks like old syntax but behaves differently.
Re: DIP 1005 - Preliminary Review Round 1
On 22.04.2017 13:54, Mike Parker wrote: DIP 1005 is titled "Dependency-Carrying Declarations". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion. An extensive discussion regarding this DIP has already taken place [1]. Thanks in advance to all who participate. Destroy! [1] http://forum.dlang.org/thread/o2psvk$1m96$1...@digitalmars.com?page=1 "* Inside any function, all uses of with are statements and obey the current language rules. * Everywhere else, ..." "* Inside any function, with (Import ImportList) is a statement that introduces a scope. Inside the with, lookup considers the import local to the declaration (similar to the current handling of nested imports). * Everywhere else, ..." Please don't do this. "This extension removes an unforced limitation of the current with syntax (allows it to occur at top level)" No, it does not. It introduces two more incompatible syntaxes that look the same, yet are different. "The drawback of this choice is the potentially confusing handling of scopes: the with statement introduces a scope, whereas the with declaration does not." It's not merely confusing, it's frustrating. I might legitimately want to use the new feature on a local declaration. As an analogy, just imagine how frustrating it would be if 'static if' was written as 'if' with different meaning depending on the scope. Just associate actual syntax to the the scope handling. The proposal would be sane if it instead introduced a new 'static with' construct that actually has the same meaning in every context. This is how it works for static if, and it is also how it will work for static foreach, so it is even consistent with other language features.
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 12:16:19 UTC, Nordlöw wrote: On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote: Is there any way I can make it `@nogc` without having to modify the code in `std.conv`? If I get this to work, I'm gonna try pushing it into std.conv. If defaultValue is not lazy, it's potentially wasteful. But at the moment, lazy are never inferred as nothrow: https://issues.dlang.org/show_bug.cgi?id=12647
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md Very solid DIP! And I like the use of `with` and it's proposed extension to be allowed in declarations, rather than introducing new syntax.
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md with (Type) and with (TemplateInstance) are always declarations and do not introduce a new scope. Does that mean we can now do things like this?: - module m; struct A { struct B { } } with (A) B b; - That's a pretty cool addition.
Re: multiple `alias this` suggestion
On Fri, Apr 21, 2017 at 08:32:55PM +, Stefan Koch via Digitalmars-d wrote: > On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote: [...] > > https://github.com/dlang/dmd/pull/3998/files > > > > It's written against C++ DMD as it was in 2014 so it may not be > > feasible anymore to easily port it to DDMD. > > This one looks easy to port. > However I am not sure if those are disired semantics and that was one > of the points raised against the PR iirc. I see. So the first thing to do is to work out the desired semantics, before we make another attempt at implementing it. T -- Who told you to swim in Crocodile Lake without life insurance??
Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT
On Saturday, 22 April 2017 at 14:22:18 UTC, John Colvin wrote: On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote: Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be informed by how a _fast_ jit-compatible x86-codegen is structured. Since I do believe that this is an interesting topic; I will give you the over-the-shoulder perspective on this. At the time of posting the video is still uploading, but you should be able to see it soon. https://www.youtube.com/watch?v=pKorjPAvhQY Cheers, Stefan Is there not some way that you could get the current interpreter-based implementation in to dmd sooner and then modify the design later if necessary when you do x86 jit? The benefits of having just *fast* ctfe sooner are perhaps larger than the benefits of having *even faster* ctfe later. Faster templates are also something that might be higher priority - assuming it will be you who does the work there. Obviously it's your time and you're free to do whatever you like whenever you like, but I was just wondering what you're reasoning for the order of your plan is? newCTFE is currently at a phase where high-level features have to be implemented. And for that reason I am looking to extend the interface to support for example scaled loads and the like. Otherwise you and up with 1000 temporaries that add offsets to pointers. Also and perhaps more importantly I am sick and tired of hearing "why don't you use ldc/llvm?" all the time...
Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT
On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote: Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be informed by how a _fast_ jit-compatible x86-codegen is structured. Since I do believe that this is an interesting topic; I will give you the over-the-shoulder perspective on this. At the time of posting the video is still uploading, but you should be able to see it soon. https://www.youtube.com/watch?v=pKorjPAvhQY Cheers, Stefan Is there not some way that you could get the current interpreter-based implementation in to dmd sooner and then modify the design later if necessary when you do x86 jit? The benefits of having just *fast* ctfe sooner are perhaps larger than the benefits of having *even faster* ctfe later. Faster templates are also something that might be higher priority - assuming it will be you who does the work there. Obviously it's your time and you're free to do whatever you like whenever you like, but I was just wondering what you're reasoning for the order of your plan is?
Re: DIP 1005 - Preliminary Review Round 1
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote: DIP 1005 is titled "Dependency-Carrying Declarations". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md Oh, this is huge, great work! Many thanks to all authors! --Ilya
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote: if (haveCommonType!(T, U)) Defined as: /// Is `true` iff `Types` all share a common type. enum bool haveCommonType(Types...) = !is(CommonType!Types == void); import std.traits : CommonType;
Re: Default-valued nothrow @nogc std.conv:to
On Saturday, 22 April 2017 at 12:14:26 UTC, Nordlöw wrote: Is there any way I can make it `@nogc` without having to modify the code in `std.conv`? If I get this to work, I'm gonna try pushing it into std.conv.
Default-valued nothrow @nogc std.conv:to
Have anyone tried to implement a variant of `std.conv.to` that can be `nothrow @nogc` if the exception handling is replaced by an extra second parameter (`defaultValue`) returned iff the call to `to` throws? I currently have a solution https://github.com/nordlow/phobos-next/blob/b7a5c589d890f6b7bef7c5f2588fa93d90d19d62/src/conv_ex.d#L10 that is `nothrow` but not (yet) `@nogc`: CommonType!(T, U) toWithDefault(T, U, S)(S value, U defaultValue) if (haveCommonType!(T, U)) { try { import std.conv : to; return value.to!T; } catch (Exception e) // assume ConvException. TODO can we capture ConvException instead make it inferred nothrow { return defaultValue; } } Is there any way I can make it `@nogc` without having to modify the code in `std.conv`? Further, can anybody think of a more consice naming than `toWithDefault`?
Re: 2.074.0-regression in move semantics
On Saturday, 22 April 2017 at 11:54:12 UTC, Nordlöw wrote: which means that the return statement at https://github.com/nordlow/gmp-d/blob/660d82b99abeef2b26ef3c9c4525d08a2aafdc55/src/gmp/z.d#L484 can no longer move the expression `y`. Note that changing the line 484 containing return y; to return move(y); instead fails as /usr/include/dmd/phobos/std/algorithm/mutation.d(1207,12): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable /usr/include/dmd/phobos/std/algorithm/mutation.d(1200,20): Error: template instance std.algorithm.mutation.moveImpl!(MpZ) error instantiating /usr/include/dmd/phobos/std/algorithm/mutation.d(1162,31): instantiated from here: trustedMoveImpl!(MpZ) src/gmp/z.d(484,24):instantiated from here: move!(MpZ) src/gmp/q.d(205,16):instantiated from here: opBinary!"/" src/gmp/z.d(168,16): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable src/gmp/z.d(921,16): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable
2.074.0-regression in move semantics
AFAICT, release 2.074.0 has regressed move semantics in function return statements. As a consequence, my package https://github.com/nordlow/gmp-d/ no longer compiles. At master branch, `dub build` now errors as Performing "debug" build using /usr/bin/dmd for x86_64. gmp-d 0.0.1+commit.126.g660d82b: building configuration "library"... src/gmp/z.d(484,20): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable src/gmp/q.d(205,16): Error: template instance gmp.z.MpZ.opBinary!"/" error instantiating src/gmp/z.d(168,16): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable src/gmp/z.d(921,16): Error: struct gmp.z.MpZ is not copyable because it is annotated with @disable /usr/bin/dmd failed with exit code 1. which means that the return statement at https://github.com/nordlow/gmp-d/blob/660d82b99abeef2b26ef3c9c4525d08a2aafdc55/src/gmp/z.d#L484 can no longer move the expression `y`. I don't understand why this specific case fails when others in the standard library apparently hasn't. Help, please.
DIP 1005 - Preliminary Review Round 1
DIP 1005 is titled "Dependency-Carrying Declarations". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The review period will end at 11:59 PM ET on May 13 (3:59 AM GMT on May 14), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, because the DIP comes from a language author and no formal review period by the language authors is necessary, the DIP will be marked "Accepted" or "Rejected" at the author's discretion. An extensive discussion regarding this DIP has already taken place [1]. Thanks in advance to all who participate. Destroy! [1] http://forum.dlang.org/thread/o2psvk$1m96$1...@digitalmars.com?page=1
Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT
On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: On Thursday, 20 April 2017 at 14:54:20 UTC, Stefan Koch wrote: On Thursday, 20 April 2017 at 14:35:27 UTC, Suliman wrote: Could you explain where it can be helpful? It's helpful for newCTFE's development. :) The I estimate the jit will easily be 10 times faster then my bytecode interpreter. which will make it about 100-1000x faster then the current CTFE. Is this apply to templates too? I recently tried some code, and templated version with about 10 instantiations for 4-5 types increased compile time from about 1 sec up to 4! The template itself was staightforward, just had a bunch of static if-else-else for types special cases. If you could share the code it would be appreciated. If you cannot share it publicly come in irc sometime. I am Uplink|DMD there.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 22:11:19 UTC, Namespace wrote: nuDist - in D you can program as free as you want. ;) void main() body { asm { naked; } }
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 19:48:53 UTC, Adrian Matoga wrote: On Friday, 21 April 2017 at 12:37:03 UTC, Mike Parker wrote: And I should add (for anyone paying attention), this is exactly the sort of thing I'm looking for more of on the D Blog. Submissions welcome :-) This, and the generally positive feedback on r and HN are quite motivating. :) I have some ideas for more articles but being a non-native English speaker I need a lot of time to make the text look at least understandable, so I usually give up quickly and move on to play with code instead. :) I'm a native speaker, but I hate writing with a passion, but I found the D community are very forthcoming with suggestions and improvements w.r.t both code and language typos and structure issues.
Re: Compare boost::hana to D
On Saturday, 22 April 2017 at 07:53:49 UTC, Johannes Pfau wrote: [1] https://www.youtube.com/watch?v=X_p9X5RzBJE [2] https://epi.github.io/2017/03/18/less_fun.html OT but is there any benefit to identify events with strings? As long as you use compile time only events I'd prefer a syntax as in https://github.com/WebFreak001/EventSystem (one benefit is that it's 100% IDE autocomplete compatible) I guess if you want runtime registration of events identifying by name is useful. But then you also somehow have to encode the parameter types to make the whole thing safe... -- Johannes I don't know about events, but dcd uses things like token!"+=" instead of giving it a name, I think it is very readable, way better than php's T_pajamajama or whatever it is/was.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Fri, 2017-04-21 at 21:20 -0700, Jonathan M Davis via Digitalmars-d wrote: > […] > I've never heard of anyone doing anything like this in any language. > Normally, you'd just say that someone is a D programmer or a C++ > programmer > or a Java Programmer, etc. But then again, I come from a C++ > background, not > a scripting language background, and the folks who primarily use > scripting > languages often tend to look at things differently. > I guess most people using scripting languages are just Bashing things together. ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Fri, 2017-04-21 at 17:20 +, Vasudev Ram via Digitalmars-d wrote: > Hi list, > > I hope the question is self-evident from the message subject. If > not, it means: what are D developers generally called (to > indicate that they develop in D)? The question occurred to me > somehow while browsing some D posts on the forums just now. > > DLanger? DLangist? D'er? Doer? :) > > I tend to favor DLanger, FWIW. I would hope none of these, but as ketmar said "programmer". Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are terms of tribalism and exclusion. They are attempts to ensure people claiming membership of the tribe reject being polyglot by pressuring them to eschew all other languages. A good programmer can work professionally with a number of languages, the psychology of programming people have data supporting this theory – if the languages have different computational models. Thus I would claim to be a programmer currently working with D for the project I am working on just now, with SCons/Python for the build system. In a while it will be C++ on another project with CMake. Later still it will be C and Meson on a different project. Further on it will be Kotlin and Frege using Gradle for yet another project. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Compare boost::hana to D
Am Wed, 19 Apr 2017 18:02:46 + schrieb Adrian Matoga : > On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote: > > I'm brushing up on my C++ to prepare for my C++Now 2017 > > presentation[1]. boost::hana is an impressive library that > > overlaps with many D features: > > > > > > http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html > > > > Have you used boost::hana? What are your thoughts on it? > > > > And please share your ideas for the presentation. There has > > been threads here about C++ closing the gap. Does D still bring > > competitive advantage or is it becoming irrelevant? (Obviously, > > some think its irrelevant already.) I'm trying to collect > > opinions... :) > > > > Thank you, > > Ali > > > > [1] > > http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html > > I was at C++ Meeting 2016 in Berlin, where Louis Dionne talked > about hana in his keynote [1]. I've summarized my feelings in a > blog post [2]. In short, you can do the same tricks in D, but > frequently there's an idiomatic way to express the same thing > just as concisely without them. > And of course, feel free to use any part of my post in your talk. > :) > > [1] https://www.youtube.com/watch?v=X_p9X5RzBJE > [2] https://epi.github.io/2017/03/18/less_fun.html > OT but is there any benefit to identify events with strings? As long as you use compile time only events I'd prefer a syntax as in https://github.com/WebFreak001/EventSystem (one benefit is that it's 100% IDE autocomplete compatible) I guess if you want runtime registration of events identifying by name is useful. But then you also somehow have to encode the parameter types to make the whole thing safe... -- Johannes