Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool": https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 4, 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, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate. Example D ``` Enum int a = 2; Enum int b = 1; ``` should be `enum`. Otherwise, YES
[Issue 18984] Debugging stack struct's which are returned causes incorrect debuginfo.
https://issues.dlang.org/show_bug.cgi?id=18984 --- Comment #4 from Manu --- This is closed right? --
Re: using tuple as value type for associative array
On Thursday, 21 June 2018 at 03:04:46 UTC, Computermatronic wrote: On Thursday, 21 June 2018 at 02:44:12 UTC, Flaze07 wrote: when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ? what["something"].first = 20 will attempt to get an element of what, then assign a member, while what2["something"] = 20 will add an element to what2 with the value of 20. Since what["something"] is not present, it will throw a range error. Try what["something"] = tuple(20, 0); instead. huh, interesting, thanks
Re: using tuple as value type for associative array
On Thursday, 21 June 2018 at 02:44:12 UTC, Flaze07 wrote: when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ? what["something"].first = 20 will attempt to get an element of what, then assign a member, while what2["something"] = 20 will add an element to what2 with the value of 20. Since what["something"] is not present, it will throw a range error. Try what["something"] = tuple(20, 0); instead.
using tuple as value type for associative array
when I do Tuple!(uint, "first", uint, "second")[string] what; //I tried aliasing the tuple as well what["something"].first = 20; I get range error but when I do uint[string] what2; what2 = 20; I get none of those range error, so...how do I use tuple as value type for associative array ?
[Issue 19011] New: visualD - not able to return to previous location after goto definition shortcut
https://issues.dlang.org/show_bug.cgi?id=19011 Issue ID: 19011 Summary: visualD - not able to return to previous location after goto definition shortcut Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: ben.stembri...@gmail.com After going to a definition of a function or variable (F12 - Edit.GotoDefinition) you are not able to return back to the previous location using other shortcuts (Ctrl+* View.BrowsePopContext or shift+F12 View.PopBrowseContext) Ive tried several versions of visual studio from 2017 down to 2005 --
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote: On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward. The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ number 1 on hn https://news.ycombinator.com/item?id=17355348 Still 2nd on r/programming. I don't really know how these things work, but it's been fun.
[Issue 19010] New: new fails on dynamic array aliases
https://issues.dlang.org/show_bug.cgi?id=19010
Issue ID: 19010
Summary: new fails on dynamic array aliases
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
Pretty simple example:
```
unittest {
alias T = int[];
T t = new T;
}
```
This doesn't seem to have ever compiled correctly. It currently fails with the
misleading error "Error: new can only create structs, dynamic arrays or class
objects, not int[]'s"
--
Re: Vibe D Examples
On Wednesday, 20 June 2018 at 22:46:16 UTC, infinityplusb wrote:
I'm trying to reacquaint myself with D, and Vibe in particular.
I notice that some of my previous working apps now don't work.
While going through the tour.dlang page, I can't seem to get
any of those sample apps working either. Nor do the apps in
Vibe's github page appear to be up to date with the recent
changes.
Are there some current, simple, working examples that I could
plagiarise to get something going?
TIA
Brian
Nevermind. Simple case of RTFM ...
-- source/app.d
import vibe.d;
void main()
{
auto settings = new HTTPServerSettings("127.0.0.1");
settings.port = 48081;
auto router = new URLRouter ;
router
.get("/", )
;
listenHTTP(settings, router);
runApplication();
}
void homeScreen(HTTPServerRequest req, HTTPServerResponse res)
{
// res.writeBody("Hello again Vibe.d: ");
res.render!("home.dt") ;
}
-- views/home.dt
doctype html5
head
title Hello World
body
p Hello template vibe
Vibe D Examples
I'm trying to reacquaint myself with D, and Vibe in particular. I notice that some of my previous working apps now don't work. While going through the tour.dlang page, I can't seem to get any of those sample apps working either. Nor do the apps in Vibe's github page appear to be up to date with the recent changes. Are there some current, simple, working examples that I could plagiarise to get something going? TIA Brian
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 05:49:15 UTC, Dukc wrote:
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote:
Is there anything I can do to improve zip, before I go ahead
and change to the faster but slightly less readable enumerate?
The problem might be that zip checks both arrays for empty
during each step, enumerate only the first one. Try appending
takeExactly(1000) on the result of zip. It might be even faster
than enumerate.
takeExactly didn't change the timings at all.
I did write a rough zip function that took advantage of random
access inputs and didn't need to account for different stopping
policies:
auto myZip(R1,R2) (R1 r1, R2 r2) {
struct MyZip(R1,R2) {
size_t index=0;
R1 rng1;
R2 rng2;
size_t length;
this (R1 r1, R2 r2) {
rng1=r1;
rng2=r2;
index=0;
length=r1.length;
}
auto empty() { return index==length; }
auto front() { return tuple(rng1[index],rng2[index]); }
void popFront() { index++; }
}
return MyZip!(R1,R2)(r1,r2);
}
This ended up being 40% faster than normal zip, both DMD 32/64.
I briefly tested with LDC and didn't notice any difference, which
I thought was weird, but didn't have time to investigate further.
That fact that zip is slower is not bad, as it provides far more
flexibility, different stopping policies, all types of ranges.
What is interesting (TBC) is the fact that it's only noticeably
slower using DMD.
Jordan
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 02:44:04 UTC, Jonathan M Davis wrote: * The null conditional operator `?.` It's been discussed before, and maybe we'll get it or something like it at some point, but it really wouldn't help much with idiomatic D. The average D program does a _lot_ less with classes than a language like C# does. Most stuff is done with structs on the stack - especially with range-based programming. That's not to say that certain types of programs couldn't benefit from such syntax, but it's going to be a lot less common than it is with C#. But it's also pretty trivial to write a helper function that does the same thing if you really want a short-hand way to do it. That's not the only use case. Recently I'm using Algebraic pretty often and I really wish that this would work: alg.peek!AThing?.method();
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 19:57:55 UTC, jmh530 wrote: I suppose that. [snip] I suppose that would be good.
Re: Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
On 06/20/2018 08:06 AM, rikki cattermole wrote: This board is for the D programming language. The one you want is https://forum.dlang.org/group/c++ And the Lesson 1 he wants is http://ddili.org/ders/d.en/hello_world.html :o) Ali
Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wednesday, 20 June 2018 at 16:10:26 UTC, H. S. Teoh wrote: On Wed, Jun 20, 2018 at 01:30:56PM +, Chris M. via Digitalmars-d wrote: On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: > This is the feedback thread for the first round of Community > Review for DIP 1015, "Deprecation and removal of implicit > conversion from integer and character literals to bool": > > [...] Yes please Seconded. T Count me in. Even though I never write code like bool foo = '\0'; I can see why this DIP is helpful and what kind of errors it can prevent.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. - This can be a problem if the project is very active. This issue was noticed by the people who converted DMD compiler from C++ to D and finally a dedicated tool was used, improved until some CI tests passed. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? - The runtime can be initialized by hand if it's required, see core.runtime.Runtime.initialize()
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? I'm a little confused...you mean like embedr [1, 2] and pyd [3], but for Octave and Matlab? The idea would that you could write functions in D and call them in Matlab/Octave, and vice-versa. I suppose that. I'm not sure adding D to the GNU Octave code base is necessarily the biggest value add... There was an old forum post years ago on the subject [4], but the link to the repository is dead. [1] https://bitbucket.org/bachmeil/embedr [2] https://github.com/bdilday/embedr [3] https://code.dlang.org/packages/pyd [4] https://forum.dlang.org/thread/op.vhjavyoc3nc...@enigma.fem.tu-ilmenau.de
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? With respect to this part of your question, you might want to check out https://dlang.org/spec/betterc.html and especially the limitations https://dlang.org/spec/betterc.html#consequences It shouldn't take much to do this, but the limitations of betterC are not minor.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas? I've looked into this a bit, but haven't had time to do anything with it. My opinion is that the starting point is to add functionality using Oct-Files. The reason is that it is the simplest way to do so in a way that you can share your work with others. That allows you to call into the Octave API and reuse that code. Given the recent work on C++ interoperability, I think this strategy is the clear winner.
Re: How an Engineering Company Chose to Migrate to D
On Wed, Jun 20, 2018 at 07:13:41PM +, bachmeier via Digitalmars-d-announce wrote: > On Wednesday, 20 June 2018 at 18:32:34 UTC, Bastiaan Veelo wrote: > > On Wednesday, 20 June 2018 at 18:21:01 UTC, Bastiaan Veelo wrote: > > > On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote: [...] > > > > number 1 on hn > > > > https://news.ycombinator.com/item?id=17355348 > > > > > > OMG how am I to respond to all the comments, I cannot see the end > > > of it! > > > > It seems I'm not supposed to: > > > > "You're posting too fast. Please slow down. Thanks." > > > > What a strange site. > > The site is intentionally designed in a way that discourages > discussion. They prefer to have comments several paragraphs long that > appear to someone with no knowledge of the matter to inject insights > into the conversation. In practice most of the comments are uninformed > BS and attempts to put others down but it is what it is. Thank you for confirming that I wasn't just being an outdated freak in the loonie bin. This is exactly my evaluation of HN (and several other similar sites), and why I find these newfangled social-media thingamajigs a huge waste of my time, and not worth the bother to sign up for. T -- Век живи - век учись. А дураком помрёшь.
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 18:32:34 UTC, Bastiaan Veelo wrote: On Wednesday, 20 June 2018 at 18:21:01 UTC, Bastiaan Veelo wrote: On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote: On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ number 1 on hn https://news.ycombinator.com/item?id=17355348 OMG how am I to respond to all the comments, I cannot see the end of it! It seems I'm not supposed to: "You're posting too fast. Please slow down. Thanks." What a strange site. The site is intentionally designed in a way that discourages discussion. They prefer to have comments several paragraphs long that appear to someone with no knowledge of the matter to inject insights into the conversation. In practice most of the comments are uninformed BS and attempts to put others down but it is what it is.
Re: Dutyl 1.5.0 released - dfmt support added
Timoses wrote: > Any ideas why autocompletion doesn't? > Opps. I suppose One should use vim's autocomplete feature : D (i_CTRL-P)
Is it feasible to slowly rewrite a C++ codebase in D?
I'm specifically thinking of the GNU Octave codebase: http://hg.savannah.gnu.org/hgweb/octave/file/@ It's a fairly old and complicated C++ codebase. I would like to see if I could slowly introduce some D in it, anywhere. Now, as I understand it, I would need to begin with making `main` a D function, because D needs to initialise the runtime. Is this correct? Another possibility might be in dlopen'able functions. Currently Octave uses so-called oct functions, which are nothing more than C++ object code that is dynamically loaded by the interpreter at runtime. They are compiled to the Octave C++ API, but we also have a Matlab-compatible C API that perhaps could be more amenable for D-ification. What are your ideas?
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 18:21:01 UTC, Bastiaan Veelo wrote: On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote: On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ number 1 on hn https://news.ycombinator.com/item?id=17355348 OMG how am I to respond to all the comments, I cannot see the end of it! It seems I'm not supposed to: "You're posting too fast. Please slow down. Thanks." What a strange site.
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 16:06:15 UTC, Ali wrote: On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ number 1 on hn https://news.ycombinator.com/item?id=17355348 OMG how am I to respond to all the comments, I cannot see the end of it!
Re: Dutyl 1.5.0 released - dfmt support added
On Wednesday, 20 June 2018 at 16:12:39 UTC, Timoses wrote: However, it doesn't seem to show any autocompletions.. Anything else I am missing? :DUjump works within the file I'm editing.. Any ideas why autocompletion doesn't?
[Issue 19009] core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=19009 --- Comment #1 from Nathan S. --- PR: https://github.com/dlang/druntime/pull/2228 --
Re: How an Engineering Company Chose to Migrate to D
On Wed, Jun 20, 2018 at 01:21:30PM +, Mike Parker via Digitalmars-d-announce wrote: > If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that > his employer was evaluating D as a candidate for migrating their code > base away from Extended Pascal. Recently, the decision was made and D > was the coice. In this post, Bastiaan tells the story of how that > came to be and how they'll be moving forward. > > The blog: > https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ > > Reddit: > https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ Inspiring story. Score another one for D! T -- The richest man is not he who has the most, but he who needs the least.
[Issue 19009] New: core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=19009 Issue ID: 19009 Summary: core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc` Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com The default `hashOf` implementation used for types that do not have `toHash` uses `toUbyte` to get the byte representation which during CTFE requires allocation but during execution does not. The compiler currently takes CTFE-only code into account when inferring attributes but we can give it some help. --
Re: Dutyl 1.5.0 released - dfmt support added
On Thursday, 23 April 2015 at 18:50:54 UTC, Idan Arye wrote: GitHub repo: https://github.com/idanarye/vim-dutyl vim.org page: http://www.vim.org/scripts/script.php?script_id=5003 Now Dutyl can use dfmt to indent and/or format D code. Formatting and indentation is done using Vim's regular operators(gq and =). Hey, glad to have found Dutyl, it sounds promising. However, it doesn't seem to be doing anything.. I made sure I installed DCD (via `brew install dcd`, so dcd is in PATH) and to run :let g:dutyl_stdImportPaths=['/Library/D/dmd/src'] (MacOS system) and :DUDCDstartServer from within vim. There's a bunch of other stuff in that directory aside from the header files: --- /Library/D/dmd/src>ls * VERSION dmd: access.d dmangle.d intrange.h scanmach.d aggregate.ddmodule.d irstate.d scanmscoff.d aggregate.hdmsc.d irstate.h scanomf.d aliasthis.ddoc.d json.d scope.h aliasthis.hdscope.d json.h sideeffect.d apply.ddstruct.d lexer.d statement.d argtypes.d dsymbol.d lib.d statement.h arrayop.d dsymbol.h libelf.d statementsem.d arraytypes.d dtemplate.dlibmach.d staticassert.d arraytypes.h dversion.d libmscoff.d staticassert.h attrib.d e2ir.c libomf.d target.d attrib.h eh.c link.d target.h backendentity.d mars.d template.h backendlicense.txt enum.h mars.h tk boostlicense.txt errors.d module.h tk.c builtin.d errors.h mtype.dtocsym.d canthrow.d escape.d mtype.htoctype.d checkwhitespace.d expression.d nogc.d tocvdebug.c clone.dexpression.h nspace.d todt.d complex.d func.d nspace.h toelfdebug.d complex_t.hglobals.d objc.d toir.d cond.d globals.h objc.h toir.h cond.h glue.d objc_glue.ctokens.d constfold.dgluelayer.dobjc_glue_stubs.c tokens.h cppmangle.dhdrgen.d objc_stubs.d toobj.c ctfe.h hdrgen.h opover.d traits.d ctfeexpr.d iasm.c optimize.d typinf.d dcast.didentifier.d osmodel.makutf.d dclass.d identifier.h parse.dutils.d declaration.d idgen.dposix.mak vcbuild declaration.h impcnvtab.dproject.ddoc version.h delegatize.d imphint.d readme.txt visitor.d denum.dimport.h root visitor.h dimport.d init.d s2ir.c win32.mak dinifile.d init.h safe.d win64.mak dinterpret.d inline.d sapply.d dmacro.d intrange.d scanelf.d druntime: CONTRIBUTING.md changelog.ddimport project.ddoc win64.mak LICENSE circle.yml mak src README.md circleci.sh osmodel.mak test benchmark def posix.mak win32.mak phobos: CONTRIBUTING.md changelog.ddetc posix.mak unittest.d LICENSE_1_0.txt circle.yml index.d project.ddoc win32.mak README.md circleci.sh osmodel.mak std win64.mak --- However, it doesn't seem to show any autocompletions.. Anything else I am missing?
Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wed, Jun 20, 2018 at 01:30:56PM +, Chris M. via Digitalmars-d wrote: > On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: > > This is the feedback thread for the first round of Community Review > > for DIP 1015, "Deprecation and removal of implicit conversion from > > integer and character literals to bool": > > > > [...] > > Yes please Seconded. T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicest of all possible ways. -- Larry Wall
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward. The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ number 1 on hn https://news.ycombinator.com/item?id=17355348
Re: tuple of delegates requires explicit type
On Wednesday, 20 June 2018 at 15:19:29 UTC, DigitalDesigns wrote: See, what the compiler is not doing is realizing that a lambda can be implicitly cast to any other lambda with the same signature. If it understood that then it should have no problem with casting the tuple implicitly. Tuple!(void function() pure nothrow @nogc @safe) Tuple!(void delegate()) a function can always be cast to a delegate(delegate is a super type as it inherits function in type logic) Functions (or rather, function pointers) do not convert implicitly to delegates in D. `void delegate()` is not a supertype of `void function()` in D. The issue is that a delegate call passes the context pointer in a spot where a function call passes a parameter. So a function pointer can't just be reinterpreted as a delegate. The conversion could be made to work by automatically wrapping the function in a delegate. Walter is understandibly against that because of the performance implication. Alternatively, it might be possible to change the delegate ABI so that the parameters are passed the same as for function calls. Older thread about that: https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool": [...] This is similar to the overload bug that c++ has with the marco NULL before it was fixed in c++11.
Re: Idea: Context sensitive attribute functions.
On Tuesday, 19 June 2018 at 21:06:16 UTC, Dennis wrote:
On Tuesday, 19 June 2018 at 19:03:44 UTC, 12345swordy wrote:
Why not use them if given the opportunity based on its context?
You can do that if you want
```
import std.stdio;
import core.stdc.stdio;
void main() @nogc {
int a = 8;
static if (__traits(compiles, new int(0))) {
writefln("writeln %d", a);
} else {
printf("printf %d", a);
}
}
```
No, it is not the same. You are testing one of the rules that is
defined by the attribute, you are not testing the attribute
itself that is derived by the context that you are in. You code
can't take into account of custom attributes.
Alexander
Re: tuple of delegates requires explicit type
On Wednesday, 20 June 2018 at 12:08:28 UTC, Jonathan M Davis
wrote:
On Wednesday, June 20, 2018 11:43:52 DigitalDesigns via
Digitalmars-d wrote:
alias f = void delegate();
Tuple!(f)[] fs;
fs ~= tuple(() { });
fails but
fs ~= Tuple!(f)(() { });
passes.
in tuple, it is seeing the lambda as void and thinks I'm trying
to append a tuple of void. I don't see why the compiler can't
see
that it works.
The types don't match.
---
import std.typecons;
alias f = void delegate();
void main()
{
pragma(msg, typeof(tuple((){})));
pragma(msg, typeof(Tuple!f((){})));
}
---
prints
Tuple!(void function() pure nothrow @nogc @safe)
Tuple!(void delegate())
tuple is instantiated and evaluated independently of what's
done with the result, so the fact that you're then appending it
to a Tuple!f[] is irrelevant. By the point it tries to append,
it's already determined the type of what it's trying to append,
and because you didn't specify the type, it's what it gets
inferred as, which is not the same type as you have in the
array.
- Jonathan M Davis
But here's the kicker!!! Trust me, it will be good!!
They are the same types! That alone says that the compiler is not
doing enough work! I mean, it is well established that the array
is of type f and the lambda is of type f!!
See, what the compiler is not doing is realizing that a lambda
can be implicitly cast to any other lambda with the same
signature. If it understood that then it should have no problem
with casting the tuple implicitly.
Tuple!(void function() pure nothrow @nogc @safe)
Tuple!(void delegate())
a function can always be cast to a delegate(delegate is a super
type as it inherits function in type logic) and the lambda may be
a function or delegate depending on context. Hence the compiler
can always assume an implicit cast of functions to delegates when
type checking on tuple.
This seems to be the missing logic either in the compiler or
possibly with tuple. If tuple could support an implicit cast or
simply upcast all functions to delegates then the code would
work...
but it seems tuple does no upcasting.
Tuple!(double)[] f;
f ~= tuple(3); // change 3 to 3.3 and it works fine!
has the same problem. We know int inherits from double(it is a
sub-type in the class of types).
This is the same problem as general implicit casting which D can
do.
Just seems that it fails for tuples because it does not apply the
implicit casts per argument.
It's easy to see that if one has n types in a tuple then it can
be implicitly converted if all the types are implicitly converted.
Conv(T(a1,...,an)) = T(Conv(a1),...,Conv(an))
Re: Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
This board is for the D programming language. The one you want is https://forum.dlang.org/group/c++
Lesson 1:Create the DOS Application, Rebuild error: c:\dm\lib\sds.lib(cinit): Previous Definition Different: __Exit ???
I am a newbe to the C/C++ Development System. I downloaded the C/C++ Development System a couple of days ago. In following the directions for Lesson 1: Create the DOS Application, when I did the Rebuild (called for in the instructions), I got an error: Error: c:\dm\lib\sds.lib(cinit) : Previous Definition Different : __Exit. The instructions say nothing about this. Is there something missing in the instructions for Lesson 1?
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:54:29 UTC, Per Nordlöw wrote:
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
Oops, this doesn't work for enums with "holes". How do I most
easily fix that?
This is my solution:
T toDefaulted(T)(scope const(char)[] value, T defaultValue) @safe
pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (member; __traits(allMembers, T))
{
case member:
mixin(`return T.` ~ member ~ `;`);
}
default:
return defaultValue;
}
}
Is there a way to avoid compile-time-string-concat plus mixin
here?
Re: Aalborg D meetup
On Wednesday, 20 June 2018 at 13:42:23 UTC, biocyberman wrote: On Tuesday, 19 June 2018 at 13:33:12 UTC, bauss wrote: On Monday, 18 June 2018 at 20:17:41 UTC, biocyberman wrote: [...] Just to be correct about the location. It would be the meeting room at the 14th floor or is it meeting room 14 at whatever floor? Feeling pretty stupid for having to ask, but just to be sure! @bauss It's better you ask now then be late for the meetup :) It is on the 14th floor. You can take the elevator after you enter the main entrance at the hospital. When you get out of the elevator and walk to the left, there is a meeting room right BEFORE you would enter the kantine.See you! Thanks a lot! Looking forward till it.
Re: Remember the Vasa! by Bjarne Stroustrup
On Saturday, 2 June 2018 at 12:08:27 UTC, drug wrote: On 02.06.2018 14:37, Bastiaan Veelo wrote: On Saturday, 2 June 2018 at 09:07:29 UTC, drug wrote: On 02.06.2018 03:49, Bastiaan Veelo wrote: interesting from a theoretical perspective. Stay tuned for an announcement... I've been staying for long enough, so let me ask - when the announcement will happen approximately? )) Approximately in the coming week :-) That's really great! Thank you. :-) At last: https://forum.dlang.org/post/spidbximoadsmdojg...@forum.dlang.org
Re: Aalborg D meetup
On Tuesday, 19 June 2018 at 13:33:12 UTC, bauss wrote: On Monday, 18 June 2018 at 20:17:41 UTC, biocyberman wrote: On Friday, 15 June 2018 at 08:45:29 UTC, Bienlein wrote: On Friday, 15 June 2018 at 07:34:07 UTC, biocyberman wrote: On Friday, 15 June 2018 at 07:20:04 UTC, Bienlein wrote: On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote: On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote: I'll be there since I live there and would be nice to see monthly meetups! :) I forgot to ask. Is it free entry? :) Yeah, and the Aalborg Akvavit is also free ? ;-) Depending on the volume you can take and how you transport to and from the meetup :) But I am taking some beer, soft drinks (saft vand?), fruit and chips. It's good for discussing socializing parts It is called soda vand, I think. Unhappily I'm about 1000 km away from Aalborg :-( I will explore further the possibility to make an online meetup after our first on-site one. If we do streaming on Youtube for example, everyone can join. Just to be correct about the location. It would be the meeting room at the 14th floor or is it meeting room 14 at whatever floor? Feeling pretty stupid for having to ask, but just to be sure! @bauss It's better you ask now then be late for the meetup :) It is on the 14th floor. You can take the elevator after you enter the main entrance at the hospital. When you get out of the elevator and walk to the left, there is a meeting room right BEFORE you would enter the kantine.See you!
Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool": [...] Yes please
How an Engineering Company Chose to Migrate to D
If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward. The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/
Re: What is the point of nothrow?
On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote: But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ? I just read stack trace from console. Initially D ecosystem focused on windows console applications, linux support came later, and compiling windows gui application is not straightforward. Simply because console support is the first thing to implement. And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ? The state is invalid in a sense that program shouldn't continue to serve its intended purpose. And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)? In most cases stack trace is enough to diagnose the error. and provides a better UX than a core dump (especially to Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself. Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident.
Re: tuple of delegates requires explicit type
On Wednesday, June 20, 2018 11:43:52 DigitalDesigns via Digitalmars-d wrote:
> alias f = void delegate();
> Tuple!(f)[] fs;
>
> fs ~= tuple(() { });
>
> fails but
>
> fs ~= Tuple!(f)(() { });
>
> passes.
> in tuple, it is seeing the lambda as void and thinks I'm trying
> to append a tuple of void. I don't see why the compiler can't see
> that it works.
The types don't match.
---
import std.typecons;
alias f = void delegate();
void main()
{
pragma(msg, typeof(tuple((){})));
pragma(msg, typeof(Tuple!f((){})));
}
---
prints
Tuple!(void function() pure nothrow @nogc @safe)
Tuple!(void delegate())
tuple is instantiated and evaluated independently of what's done with the
result, so the fact that you're then appending it to a Tuple!f[] is
irrelevant. By the point it tries to append, it's already determined the
type of what it's trying to append, and because you didn't specify the type,
it's what it gets inferred as, which is not the same type as you have in the
array.
- Jonathan M Davis
Re: tuple of delegates requires explicit type
On Wednesday, 20 June 2018 at 11:43:52 UTC, DigitalDesigns wrote:
alias f = void delegate();
Tuple!(f)[] fs;
fs ~= tuple(() { });
fails but
fs ~= Tuple!(f)(() { });
passes.
in tuple, it is seeing the lambda as void and thinks I'm trying
to append a tuple of void. I don't see why the compiler can't
see that it works.
It's because if you don't specify any types, the compiler creates
a template function so type inference for the arguments/return
type can take place. It could probably be inferred without making
the literal a template, but that's just how it's done currently.
tuple of delegates requires explicit type
alias f = void delegate();
Tuple!(f)[] fs;
fs ~= tuple(() { });
fails but
fs ~= Tuple!(f)(() { });
passes.
in tuple, it is seeing the lambda as void and thinks I'm trying
to append a tuple of void. I don't see why the compiler can't see
that it works.
[Issue 17067] D header file generation includes excess imports
https://issues.dlang.org/show_bug.cgi?id=17067
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from RazvanN ---
This is probably a WONTFIX since the header generation is done immediately
after the parsing phase so at that point no symbol resolution is done to see
which symbols come from which imports and the safe thing to do is to just put
them there; a workaround for this is to use scoped imports :
import std.stdio;
class Foo
{
void bar()
{
import std.stdio : writeln;
writeln("Hello world!");
}
}
--
Re: Nothrow std.conv.to with explicit default value
On Wednesday, June 20, 2018 09:37:00 Per Nordlöw via Digitalmars-d-learn wrote: > On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote: > > On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer > > > > wrote: > >> It just means re-doing std.conv.to, which is pretty hairy, but > >> also pretty well-organized. > > > > Ok. Where in std.conv do the string-to-enum conversions take > > place? > > AFAICT, string-to-enum-conversion must include a switch > containing a static foreach over all the enumerators, right? If you want to know where std.conv deals with converting enums, look for EnumMembers, since that's the trait to get all of the members of an enum. - Jonathan M Davis
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:37:00 UTC, Per Nordlöw wrote:
AFAICT, string-to-enum-conversion must include a switch
containing a static foreach over all the enumerators, right?
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
default:
return defaultValue;
}
}
@safe pure nothrow /*TODO @nogc*/ unittest
{
enum E { unknown, x, y, z }
assert("x".toDefaulted!(E)(E.init) == E.x);
assert("_".toDefaulted!(E)(E.init) == E.unknown);
}
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:52:04 UTC, Per Nordlöw wrote:
My suggestion for nothrow @nogc string-to-enum conversion with
default value
T toDefaulted(T)(scope const(char)[] value,
T defaultValue) @safe pure nothrow @nogc
if (is(T == enum))
{
switch (value)
{
static foreach (index, member; __traits(allMembers, T))
{
case member:
return cast(T)(index);
}
Oops, this doesn't work for enums with "holes". How do I most
easily fix that?
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 09:27:14 UTC, Per Nordlöw wrote: On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer wrote: It just means re-doing std.conv.to, which is pretty hairy, but also pretty well-organized. Ok. Where in std.conv do the string-to-enum conversions take place? AFAICT, string-to-enum-conversion must include a switch containing a static foreach over all the enumerators, right?
Re: Nothrow std.conv.to with explicit default value
On Monday, 18 June 2018 at 21:10:03 UTC, Steven Schveighoffer wrote: It just means re-doing std.conv.to, which is pretty hairy, but also pretty well-organized. Ok. Where in std.conv do the string-to-enum conversions take place?
Re: LDC 1.10.0
Great to see LDC being as up to date with DMD as possible quickly. Sadly due to a Phobos bug, I need D 2.081.0 :-( Hopefully the Debian, Fedora, Homebrew, and Linuxbrew packagers get LDC 1.10.0 out quickly. On Tue, 2018-06-19 at 22:10 +, kinke via Digitalmars-d-announce wrote: > Hi everyone, > > on behalf of the LDC team, I'm glad to announce LDC 1.10. The > highlights of this version in a nutshell: > > * Based on D 2.080.1. > * Win64: Breaking ABI change by passing vectors efficiently in > registers. > * Config file extensions for cross-compilation. > * Support for DragonFly BSD. > * Various fixes, most notably wrt. exception stack traces on > Linux. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.10.0 > > Thanks to all contributors! -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1 Begins
The first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", has begun. To participate, please visit the review thread for the details: https://forum.dlang.org/post/xfhfmvyloruiikrej...@forum.dlang.org *Please leave all feedback in the review thread rather than here!* Thanks!
DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool": https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 4, 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, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate.
Re: LDC for iOS
On Friday, 27 February 2015 at 11:11:36 UTC, Chris wrote: On Thursday, 26 February 2015 at 18:35:00 UTC, Dan Olson wrote: I think this all is in good enough shape that someone else should give it a try. https://github.com/smolt/ldc-iphone-dev This is an LDC development sandbox for iPhone iOS. It glues together various pieces needed to build an LDC cross compiler targeting iPhoneOS. It also includes a few samples to show how to get started. The compiler and libraries are in good enough shape to pass the druntime/phobos unittests with a few minor test failures (see project README.md). This means someone could, if so inclined, build their D library and use it in an iOS App. Currently based on LDC 0.15.1 (DMD v2.066.1) and LLVM 3.5.1. There are no prebuild binaries, so you have to do it yourself. Nobody has reported yet on trying to build beside me, so there may be potholes. Enjoy, Dan Thank you very much! Although I cannot test it right now (working mainly on Linux), I will soon give it a go, because we've been asked several times whether one of our apps will be available on the iPhone/iPad one day. This is very important work and, again, I thank you for your efforts. Hi Dan Olson, This is very great work but the ldc version is too old. I try patch it into last ldc master branch get a lot error(thanks Joakim for a lot help). Can you help to check what need to be modify to made it buildable ? (It require modify some file like abi-ios* to work).
Re: IOS support status
On Wednesday, 20 June 2018 at 05:26:25 UTC, Joakim wrote: Do you mean ltsmaster or master? There shouldn't be much change with the former. master branch. The TLS patches shouldn't be needed after llvm 3.8 or so, ie you should be able to use a stock llvm for iOS: https://forum.dlang.org/thread/m237o97vf0@comcast.net this is great. That makes no sense: there are no C++ files in the runtime, only C and D. Anyway, if you only care about betterC, you don't want to build the runtime, so doesn't matter. My suggestion is that you simply build his working ldc for iOS project, but with the betterC patch I linked you backported. Once you're sure that's working, you can try these more advanced steps. Have you tried that? It's not clear. the origin ldc with your patch is working. but I find it is very limit betterC support with old version(some code will not work, and fixed at late dmd/ldc version). The patched ldc not build because a lot old code Dan Olson write is not working any more( ldc cpp interface changed, or llvm cpp interface changed). I try to fix but never get it working. (I patch all 36 files)
[Issue 18969] 'need this for ' when passing field or method as template parameter
https://issues.dlang.org/show_bug.cgi?id=18969
--- Comment #1 from Simen Kjaeraas ---
Related:
import std.meta : Alias;
alias getMember(alias T, string name) = Alias!(__traits(getMember, T, name));
struct S {
int i = 0;
}
unittest {
S s;
getMember!(s, "i") = 2;
}
--
[Issue 18995] std.array.array doesn't free elements
https://issues.dlang.org/show_bug.cgi?id=18995 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18995] std.array.array doesn't free elements
https://issues.dlang.org/show_bug.cgi?id=18995 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/4fe18b905526b4c1d0fb19aa28ccfcddf27ffcdc Fix issue 18995 - Make sure GC calls destructor when using std.array.array https://github.com/dlang/phobos/commit/db66b82b178480a636024371d76d016e6ee03971 Merge pull request #6584 from schveiguy/fix18995 Fix issue 18995 - Make sure GC calls destructor when using std.array.array merged-on-behalf-of: Petar Kirov --
