Re: dmd -betterC

Kagamin wrote: On Wednesday, 21 June 2017 at 06:21:37 UTC, ketmar wrote: but refusing to generate such strings for *all* code They are not useful enough for that, in 99% of cases location of assert is enough to know what's wrong, when it isn't, the string is not going to tell where it went

Re: dmd -betterC

Sebastien Alaiwan wrote: On Wednesday, 21 June 2017 at 05:35:42 UTC, ketmar wrote: asserts on embedded systems? O_O code built without -release for embedded systems? O_O embedded system != production system. You still need to debug the code, and at some point, you have to load it on a real

Re: dmd -betterC

Sebastien Alaiwan wrote: On Wednesday, 21 June 2017 at 03:57:46 UTC, ketmar wrote: "bloatsome"? i don't think so. those generated messages is small (usually 20-30 bytes), and nothing comparing to druntime/phobos size. Yeah, but what if you're already working without runtime and phobos? it

Re: dmd -betterC

Walter Bright wrote: On 6/20/2017 3:07 PM, Adam D. Ruppe wrote: On Tuesday, 20 June 2017 at 20:50:14 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6901 We should generate the default string from the expression for D too. (at a minimum, I'd actually like to see every variable

Re: Analysis of D GC

Dmitry Olshansky wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html "...the dubious optimization of no interior pointers..." this is the ONLY (i emphasise it!) way i were able to make my

Re: Analysis of D GC

safety0ff wrote: On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote: On Mon, Jun 19, 2017 at 10:50:05PM +, Adam D. Ruppe via Digitalmars-d wrote: What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some

Re: Analysis of D GC

H. S. Teoh wrote: He mentioned the "fork trick", which I assume refers to how Linux's implementation of fork() uses copy-on-write rather than immediately duplicating the parent process' memory structures. There was a D1 GC some time ago that depended on this behaviour to speed up the

Re: Operator Overloading + / ~

Martin Tschierschke wrote: Just a thought it might be useful for cut-n-paste when porting code: Would it be possible to define an operator overloading for '+'-Operator for strings to work as append? (like ~). I understand, that '~' is in general a better choice than '+', so this is of more

Re: core.math.rndtonl: invalid return type or description?

ag0aep6g wrote: On 06/19/2017 12:45 PM, ketmar wrote: ag0aep6g wrote: [...] If this is the same function: , then it should return a C long, which I guess is a D int on 32 bits. And surprise: that works. no, there is `rndtol()` and

Re: core.math.rndtonl: invalid return type or description?

p.s.: it is *important* to use `core.math.rndtonl`! this is compiler intrinsic (or at least it should be), and it won't be detected as intrinsic outside of `core.math`.

Re: core.math.rndtonl: invalid return type or description?

ag0aep6g wrote: On 06/19/2017 10:04 AM, ketmar wrote: core.math.rndtonl is declared as this: extern (C) real rndtonl(real x); Is rndtonl a Digital Mars C thing? yes, it looks like DMC library function. thus, is should be versioned out on non-DMC builds. another bug. ;-) It has no

core.math.rndtonl: invalid return type or description?

core.math.rndtonl is declared as this: extern (C) real rndtonl(real x); yet it's description says: "...If the integer value of x is greater than long.max, the result is indeterminate." it looks like it either should return `long`, or this part of description was copypasted from

Re: Life in the Fast Lane (@nogc blog post)

Guillaume Piolat wrote: On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote: This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just

Re: Isn't it about time for D3?

Moritz Maxeiner wrote: Is D perfect? No, not by any stretch of the definition, but it is still (by far) the least worst choice out there, no matter how good the tooling for other languages is or becomes. exactly my feelings! ;-)

Re: Isn't it about time for D3?

Wulfklaue wrote: On Wednesday, 14 June 2017 at 21:20:58 UTC, ketmar wrote: yeah. D should silently miscompile old code too: it seems that this is exactly what people want! Please point out the people who advocate for D silently miscompiling old code... Because i have yet to see anybody in

Re: Isn't it about time for D3?

H. S. Teoh wrote: On Wed, Jun 14, 2017 at 11:45:43PM +0300, ketmar via Digitalmars-d wrote: Ola Fosheim Grøstad wrote: On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled

Re: Isn't it about time for D3?

Ola Fosheim Grøstad wrote: On Wednesday, 14 June 2017 at 12:22:36 UTC, Russel Winder wrote: If a code is to be left untouched but the compiler not archived then the code must be recompiled and amended as needed with each new compiler that is accepted in the workflow. I don't disagree with

Re: Implementing interfaces using alias this

Balagopal Komarath wrote: On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote: interfaces *require* a full-featured class, with VMT, and some hidden pointers to support hidden interface machinery. I don't think that is the problem here. The type Test!Duck is a class and that type is

Re: Implementing interfaces using alias this

Mike B Johnson wrote: I don't think it has to do with pasting code. d.Quack() is well defined through the alias. Inheritance requires that a Quack() exists, and it does, through the alias. The compiler could easily create an implementation wrapper that uses the alias this. this is called

Re: Implementing interfaces using alias this

Balagopal Komarath wrote: On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote: Balagopal Komarath wrote: Why doesn't this work? The Test!Duck type has a void quack() method but the compiler says it is not implemented. 'cause `alias this` is *not* a tool that can be used to emulate

Re: Implementing interfaces using alias this

Balagopal Komarath wrote: Why doesn't this work? The Test!Duck type has a void quack() method but the compiler says it is not implemented. 'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the

Re: Isn't it about time for D3?

Wulfklaue wrote: On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote: Patrick Schluter wrote: the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a

Re: Makefile experts, unite!

Ralph Amissah wrote: On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d wrote: And where do existing D build systems fit into the picture, I seem to recall this general discussion around the announcement of "button", which seems interesting, potentially

Re: Isn't it about time for D3?

crimaniak wrote: If it depended on me, I would declare an embargo on language changes that's why we (me, and others like me ;-) need D3. i don't need "better phobos", for example ('cause i'm trying to aboid using phobos anyway), but i really need named arguments (`foo(a:42, b:"hello")`). i

Re: Isn't it about time for D3?

Patrick Schluter wrote: Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution? I haven't

Re: Isn't it about time for D3?

jmh530 wrote: Nevertheless, C++ is still a constantly evolving language. one of the key features of evolution is removing old and rudimentary things. without this, it is not evolution, it is mutilation...

Re: Isn't it about time for D3?

Sebastien Alaiwan wrote: My point precisely was that "not splitting D1/D2" might correspond to "doing things right". "not splitting" here means "we're stuck with D1". deprecation cycle of several years (not counting the time required to actually *start* the process) means "no evolution".

Re: Makefile experts, unite!

Sebastien Alaiwan wrote: On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote: Sebastien Alaiwan wrote: The selling points, to me, are: 1) the automatic dependency detection through filesystem hooks 2) recipes also are dependencies 3) the genericity/low-level. I believe build systems should

Re: Isn't it about time for D3?

Sebastien Alaiwan wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well,

Re: Makefile experts, unite!

H. S. Teoh wrote: i'm pretty sure that i *don't* want to know more. ;-)

Re: Weird template instantiation problem

Arafel wrote: I actually found a workaround for the original issue: yeah, sorry for not proposing a workaround: i thought that you already did it, and now you're just interested why the original code doesn't work. ;-) i think that this is a bug (or, rather, unimplemented feature).

Re: Generic operator overloading for immutable types?

Gary Willoughby wrote: In the following code is there any way to make the `opBinary` method generic to be able to accept immutable as well as a standard type? The code currently passes the unit test but I wonder if I could get rid of the duplication to overload the operator? I'm failing

Re: Makefile experts, unite!

p.s.: btw, k8jam is not a "make wrapper", it is a self-contained build system, in one ~100 kb binary. ;-)

Re: Makefile experts, unite!

H. S. Teoh wrote: and i really mean it: it was less than a second even for a huge projects, where linking alone took long enough that i could get coffee and cigarette. ;-) [...] Your project is not huge enough. :-D ~20MB, >2000 source files. for *this* it was something like 0.5-3 seconds

Re: Weird template instantiation problem

p.s.: while i understand the technical reason for second error message, it is still random and confusing.

Re: Weird template instantiation problem

more funny compiler messages: alias xx = size_t function (int[]); struct S1(T, typeof(xx) X) {} void main() { S1!(int, defaultChooser!int) s; } Error: type uint function(int[]) is not an expression but: struct S2(T, typeof(defaultChooser!T)

Re: Makefile experts, unite!

p.s.: like, i've seen one Fallout 2 recreatoin project where they're doing translation of screen coords to hex coords not with two simple formulas, but by looping over 4 (200x200) hex objects (objects!), and calling *virtual* method to ask if a hex contains such coords. and you know what?

Re: Makefile experts, unite!

H. S. Teoh wrote: Don't forget tup, and others inspired by it, which use modern OS features to reduce the cost of determining what to build to an O(1) database lookup rather than an O(n) whole-source tree scan. added complexity for nothing. disks gradually replacing with ssd, amount of RAM

Re: Makefile experts, unite!

Sebastien Alaiwan wrote: On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote: Jonathan M Davis wrote: It's certainly a pain to edit the makefiles though and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not

Re: Makefile experts, unite!

Sebastien Alaiwan wrote: On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote: Jonathan M Davis wrote: It's certainly a pain to edit the makefiles though and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not

Re: Makefile experts, unite!

Sebastien Alaiwan wrote: The selling points, to me, are: 1) the automatic dependency detection through filesystem hooks 2) recipes also are dependencies 3) the genericity/low-level. I believe build systems should let me define my own abstractions, instead of trying to define for me what an

Re: Makefile experts, unite!

Jonathan M Davis wrote: It's certainly a pain to edit the makefiles though and don't forget those Great Copying Lists to copy modules. forgetting to include module in one of the lists was happened before, not once or twice...

Re: Makefile experts, unite!

Ali Çehreli wrote: On 06/11/2017 12:27 PM, ketmar wrote: p.s.: or replacing make-based build system with D-based. as we need working D compiler to compile dmd anyway, i see no reason to not use it more. I had the pleasure of working with Eyal Lotem, main author of buildsome. The buildsome

Re: Isn't it about time for D3?

solidstate1991 wrote: E already exists (https://en.wikipedia.org/wiki/E_(programming_language) + AmigaE), two things having the same name often doom one of them into obscurity (see SDLang, which originally was called SDL). and there were several "D"s too. ;-) There were already a few changes

Re: Isn't it about time for D3?

Guillaume Piolat wrote: On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote: Well, no thanks. The very same strategy halved the community for D1/D2 split and almost killed D. as you can see, D is alive and kicking, and nothing disasterous or fatal happens.

Re: Expressing range constraints in CNF form

Walter Bright wrote: On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote: Ostensibly the function is trivial: bool msg(string) { return true; } It doesn't change the semantics. The compiler would recognize it as an intrinsic and would print the message if the clause to its left has failed.

Re: Expressing range constraints in CNF form

Walter Bright wrote: On 6/11/2017 8:25 AM, Andrei Alexandrescu wrote: Ostensibly the function is trivial: bool msg(string) { return true; } It doesn't change the semantics. The compiler would recognize it as an intrinsic and would print the message if the clause to its left has failed.

Re: Makefile experts, unite!

Andrei Alexandrescu wrote: Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I

Re: Makefile experts, unite!

Andrei Alexandrescu wrote: Phobos' posix.mak offers the ability to only run unittests for one module: make std/range/primitives.test BUILD=debug -j8 ... or package: make std/range.test BUILD=debug -j8 It runs module tests in parallel and everything. This is definitely awesome. But say I

Re: Isn't it about time for D3?

Mike B Johnson wrote: On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote: Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit

Re: Isn't it about time for D3?

Guillaume Piolat wrote: On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote: I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Well, no thanks. The very same strategy halved the community for D1/D2 split and almost

Re: Isn't it about time for D3?

Ola Fosheim Grøstad wrote: On Sunday, 11 June 2017 at 05:24:25 UTC, ketmar wrote: and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we D--? Out of curiosity;

Re: Isn't it about time for D3?

Mike B Johnson wrote: Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They

Re: Isn't it about time for D3?

Seb wrote: On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote: Adam D. Ruppe wrote: I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet

Re: Isn't it about time for D3?

Liam McGillivray wrote: On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote: ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary

Re: Isn't it about time for D3?

Adam D. Ruppe wrote: On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote: Dev resources are stretched thin as it is, I doubt the core team would go for it. I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this

Re: Isn't it about time for D3?

Liam McGillivray wrote: I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2. ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-)

Re: DMD test suite not runnable on Debian/Linux

H. S. Teoh wrote: On Sat, Jun 10, 2017 at 02:27:13AM +0300, ketmar via Digitalmars-d wrote: H. S. Teoh wrote: On a tangential note, now that I finally got the miserable test suite running, I've managed to figure out that the problem in my dmd PR was caused by src/ddmd/globals.h not being

Re: DMD test suite not runnable on Debian/Linux

H. S. Teoh wrote: On a tangential note, now that I finally got the miserable test suite running, I've managed to figure out that the problem in my dmd PR was caused by src/ddmd/globals.h not being auto-generated from src/ddmd/globals.d, so when I added new fields to the Global struct, the C++

Re: DMD test suite not runnable on Debian/Linux

it's even worser than that: unittests ultimatively fails with binutils 2.28 (at least on x86 without PIC), so i was forced to downgrade binutils to 2.26.

Re: a way to specily floating-point numbers as bit patters

Honey wrote: On Friday, 9 June 2017 at 16:34:28 UTC, ketmar wrote: Try -0.1685f. it doesn't matter if i can find the decimal representation for the given bit pattern or not. the whole post is about removing the need to rely on lossy binary->decimal->binary conversions. Lossless

Re: a way to specily floating-point numbers as bit patters

Basile B. wrote: On Friday, 9 June 2017 at 17:18:43 UTC, ketmar wrote: Basile B. wrote: enum binFloat = *cast(float*) i was SO sure that this won't work in CTFE that i didn't even tried to do it. "it will fail anyway, there is no reason in trying!" ;-) You can do the arithmetic as

Re: a way to specily floating-point numbers as bit patters

Basile B. wrote: enum binFloat = *cast(float*) i was SO sure that this won't work in CTFE that i didn't even tried to do it. "it will fail anyway, there is no reason in trying!" ;-)

Re: a way to specily floating-point numbers as bit patters

Petar Kirov [ZombineDev] wrote: Do HexFloats (http://dlang.org/spec/lex#HexFloat) help? hm. i somehow completely missed "%a" format specifier! yeah, "-0x1.6ep-3" did the trick. tnx. i should do my homework *before* posting big rants, lol.

Re: a way to specily floating-point numbers as bit patters

Basile B. wrote: ps. "-0.17 0xBE2AAAC1". it's not the same! (and yes, it matters). -0.17f is not representable as a 32 bit float. The actuall value that's stored is -0.169994592259765625, hence the difference. See https://www.h-schmidt.net/FloatConverter/IEEE754.html and

Re: a way to specily floating-point numbers as bit patters

Honey wrote: On Friday, 9 June 2017 at 16:07:36 UTC, ketmar wrote: one of my calculated values is `-0.17`, which has bit-pattern of 0xBE2AAAB7. now, let's say i want to use this number in my code: float v = -0.17f; writefln("%f 0x%08X", v, *cast(uint*)); ps.

a way to specily floating-point numbers as bit patters

let's say that i have precomputed some `float`-typed tables, and now i want to use 'em in my code. for example, a table for Lagrange series. the table itself is like 10 numbers, but the code calculating it rather big, and it depends of architecture (so it can yield different results on

Re: Compile-Time Sort in D

Steven Schveighoffer wrote: At least in terms of i/o printing to the console or whatnot, it would be cool to be able to do so at compile-time just directly with writeln. As of now, a CTFE function can't call writeln, and it also can't pragma(msg, ...) because it has to be written as a runtime

Re: DMD [-O flag] vs. [memory allocation in a synchronized class]

realhet wrote: On Thursday, 8 June 2017 at 10:48:41 UTC, ketmar wrote: worksforme with -O, and with -O -inline. I forgot to mention, that I'm generating win32 output. DMD32 D Compiler v2.074.0 mine: GNU/Linux, 32 bit, dmd git HEAD.

Re: DMD [-O flag] vs. [memory allocation in a synchronized class]

worksforme with -O, and with -O -inline.

Re: vibe.d on Web Framework Benchmarks

Ozan wrote: On Wednesday, 7 June 2017 at 09:44:55 UTC, Ali Çehreli wrote: Is there an issue with the tests? Surprised that vibe.d is not higher in the rating... https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune Same for me. I used a lot of Java (Jetty, Tomcat) and Groovy

Re: Alias this and inheritance

Jacob Carlborg wrote: The following code does not compile: void foo(string a) {} class Base { alias bar this; string bar() { return ""; } } class Sub : Base {} void main() { auto sub = new Sub; foo(sub); } But if the "alias this" is copied/moved to

Re: Label as Values in D ?

Patric Dexheimer wrote: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Is possible to use Label as Values in D? Or there is a way to do dynamic goto statements? Ps: This is out of curiosity / performance reasons. I know the potential of bad design / ugly code ;) as we have nested

Re: Concept proposal: Safely catching error

Olivier FAURE wrote: On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote: tbh, i think that it adds Yet Another Exception Rule to the language, and this does no good in the long run. "oh, you generally cannot do that, except if today is Friday, it is rainy, and you've seen pink unicorn at

Re: Concept proposal: Safely catching error

Olivier FAURE wrote: What do you think? Does the idea have merit? Should I make it into a DIP? tbh, i think that it adds Yet Another Exception Rule to the language, and this does no good in the long run. "oh, you generally cannot do that, except if today is Friday, it is rainy, and you've

Re: D and GDB

Russel Winder wrote: I thought I had left SIGSEGV debugging behind, but it seems not. However whilst the C++/CLion debug tooling is excellent, D seems to be without. I guess there must be some gdb magic I am missing, but: Program received signal SIGSEGV, Segmentation fault. 0x7fffc788

Re: C macros vs D can't do the right thing

Jacob Carlborg wrote: Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work. yeah. that's what Phobos does, for example.

Re: C macros vs D can't do the right thing

Russel Winder wrote: Now the D Way says... ..use templates! ;-) it is not really possible to guess what macro author means (to do that, dstep should be able to actually *understand* the code), so it tries to do what is used more often. that is, it's dstep failed guess.

Re: DIP 1003 (Remove body as a Keyword) Accepted!

Petar Kirov [ZombineDev] wrote: Personally, making contracts less verbose and more powerful is much higher on my list (I don't remember ever needing to use 'body' as an identifier, but I see why is it important for many domains) yeah. i'm really tired to use `flesh` instead of it. and i have

Re: Erroneous usage of variable capture in loops

FreeSlave wrote: As known this code will not work as we may expect: import std.stdio; void main(string[] args) { void delegate ()[] delegates; foreach(i; 0..10) { int j = i; delegates ~= delegate() { writeln(j); }; } foreach(dlgt;

Re: Bad array indexing is considered deadly

Steven Schveighoffer wrote: On 5/31/17 10:07 AM, Steven Schveighoffer wrote: Here is complete implementation (should be @safe too): struct ExArr(T, size_t dim) { T[dim] _value; alias _value this; ref inout(T) opIndex(size_t idx, string fname = __FILE__, size_t linenum = __LINE__)

Re: Bad array indexing is considered deadly

Steven Schveighoffer wrote: On 5/31/17 9:37 AM, Adam D. Ruppe wrote: On Wednesday, 31 May 2017 at 13:04:52 UTC, Steven Schveighoffer wrote: What are your thoughts? Have you run into this? If so, how did you solve it? I don't use vibe, but my cgi.d just catches RangeError, kills the

Re: purity question

Rene Zwanenburg wrote: On Tuesday, 30 May 2017 at 11:34:52 UTC, ketmar wrote: If malloc were marked as pure, wouldn't that mean it must return the same pointer every time you call it with the same size? of course. but D "pure" is not what other world knows as "pure". we love to mess with

Re: purity question

Rene Zwanenburg wrote: On Monday, 29 May 2017 at 01:36:24 UTC, Jonathan M Davis wrote: A simple example: anything that has a malloc/free pair. Yeah, if you do it right, you should be fine, but you have to do it right, and it's very easy to miss some detail that makes it wrong to insist to

Re: purity question

Ola Fosheim Grøstad wrote: On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote: pure. and while various functions in std.math, for example, are marked `pure`, they aren't too. Out of curiosity, which functions in std.math aren't "pure" in the D sense? almost all of them, 'cause they

Re: purity question

Brad Roberts wrote: libraries that themselves aren't marked pure, there's a real need for escape hatches. A simple example: anything that has a malloc/free pair. they aren't pure. it is a sad misconception about purity, which D makes even more complex by allowing to mark, for example,

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Nick Sabalausky (Abscissa) wrote: In response to any claim that this isn't a real problem in practice, I submit the possibility that, if it indeed isn't a real problem, maybe that's *because* of people (like Stefan and ketmar) simply avoiding the feature entirely so that it *doesn't* become a

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Nicholas Wilson wrote: On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote: Imagine you wrote a function void foo(ref int a) { if (std.random.uniform(0, 10) == 0) a = 0; // Actual code doing something } [...] It seems nice in theory but how will it interact with generic code?

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Ola Fosheim Grostad wrote: This is information that a good IDE could be designed to provide. when people start talking about how IDE can help to solve particular language problem, it is a clear sign of bad language design.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Meta wrote: On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote: Meta wrote: If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Stefan Koch wrote: Personally I stay away from ref precisely because of it's silent caller syntax. same here. i prefer to use pointers instead, 'cause they are visible at the calling site.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Meta wrote: If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the function takes its parameters by ref or out... You're should've RTFM. now

Re: DMD now has colorized syntax highlighting in error messages

Walter Bright wrote: https://github.com/dlang/dmd/pull/6777 It turned out to be unexpectedly easy to implement. The only downside is now we have to rather tediously tweak the error message texts so they use backticks. sorry for being rude, but this is exactly the example of things

Re: Processing a gzipped csv-file by line-by-line

Nordlöw wrote: What's fastest way to on-the-fly-decompress and process a gzipped csv-fil line by line? Is it possible to combine http://dlang.org/phobos/std_zlib.html with some stream variant of File(path).byLineFast ? iv.vfs[0] can do that (transparently decompress gzip files, and

Re: dmd: can't build on Arch Linux or latest Ubuntu

Marco Leise wrote: Am Wed, 10 May 2017 20:59:33 +0300 schrieb ketmar : On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote: I can't build dmd on Arch Linux anymore. I'm told it's because of a binutils update. Annoying. yeah, the great thing. i was hit

Re: dmd: can't build on Arch Linux or latest Ubuntu

Seb wrote: On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote: I can't build dmd on Arch Linux anymore. I'm told it's because of a binutils update. Annoying. Yep, at least running the tests on Phobos fails due to changes in binutils 2.28, see this bug report for more details:

Re: readf interferes with readln

Bastiaan Veelo wrote: Hi, I am having trouble explaining the following to someone learning D. Can someone explain why readln has different behaviour when it is preceded by readf? Suppose we want to not end the program before the user presses Enter by having readln at the end of main():

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

Vasudev Ram 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?

Re: Interpolated strings

Gary Willoughby wrote: Go and Rust are both smashing D in popularity and user share, maybe we could learn why that's the case. 'cause go backed by google, and rust backed by mozilla.

Re: Playing arround with mixin - alias?

Martin Tschierschke wrote: i doubt so. So my "solution" on how to get a short cut for using: writeln(mixin(interp!"${name} you are app. ${age*365} days old")); .. NEVER. EVER. USE. THE. FOLOWING. IN. YOUR. CODE. NEVER!!! import std.stdio; mixin template usesexpand() { import

<    1   2   3   4   5   6   7   8   9   10   >