Re: [OT] Re: Problems with -fPIC, libraries and exceptions (in linux?)

On Sunday, 17 July 2016 at 05:07:00 UTC, Basile B. wrote: On Saturday, 16 July 2016 at 20:13:00 UTC, Seb wrote: On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should

Re: unittests not being run

On 07/17/2016 12:38 AM, Seb wrote: > There is no need for a module, but dub by default only checks files in > the 'source' folder. The file is already in the 'source' folder. > For such simple tests you could also run them directly with rdmd > -unittest. There is an additional -main flag if you

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote: actually, `foreach (v; rng)` looks like `foreach` is *reusing* *existing* *variable*. most of the time you can put `immutable` or something like that there to note that it is not reusing (purely cosmetical thing), but sometimes you

Re: DIP1001: Exception Handling Extensions

On 17/07/2016 5:35 AM, Superstar64 wrote: On Saturday, 16 July 2016 at 12:42:49 UTC, Andrei Alexandrescu wrote: Work much appreciated. Looks like the new community process works! -- Andrei I'm not sure you understand, I rejected my own PR. Exactly! It works :)

Re: Autotesting dub packages with dmd nightly

On 17/07/2016 8:34 AM, Sebastiaan Koppe wrote: Just to let you guys know - and to be sure no one is doing the same - I decided to go ahead and *start* writing an autotester that will fetch dmd nightly and unittest each dub package. It will be using a classic master-worker architecture and will

D's exact stack convention for D and C/C++

I am trying to debug some really messed up code that makes no sense. It calls in some code that doesn't seem to be using the standard calling convention. The function definitions are exactly the same in both D and C++. ->func(param1, param2, param3, param4); The call stack setup by C++

Re: Autotesting dub packages with dmd nightly

On Saturday, 16 July 2016 at 20:34:49 UTC, Sebastiaan Koppe wrote: Just to let you guys know - and to be sure no one is doing the same - I decided to go ahead and *start* writing an autotester that will fetch dmd nightly and unittest each dub package. It will be using a classic master-worker

Re: Vision for the D language - stabilizing complexity?

On Sun, Jul 17, 2016 at 02:59:42AM +, Nobody via Digitalmars-d wrote: > On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote: > > On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote: > > > On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote: > > > > On 7/7/2016 5:56 PM, deadalnix

Re: Vision for the D language - stabilizing complexity?

On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote: 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't mean to ever use. Don't we already have this in the form

Re: Vision for the D language - stabilizing complexity?

On Saturday, 9 July 2016 at 00:14:34 UTC, Walter Bright wrote: On 7/8/2016 2:58 PM, Ola Fosheim Grøstad wrote: On Friday, 8 July 2016 at 21:24:04 UTC, Walter Bright wrote: On 7/7/2016 5:56 PM, deadalnix wrote: While this very true, it is clear that most D's complexity doesn't come from there.

Re: D's exact stack convention for D and C/C++

On Sunday, 17 July 2016 at 01:30:31 UTC, Adam Sansier wrote: I am trying to debug some really messed up code that makes no sense. It calls in some code that doesn't seem to be using the standard calling convention. The function definitions are exactly the same in both D and C++.

[OT] Re: Problems with -fPIC, libraries and exceptions (in linux?)

On Saturday, 16 July 2016 at 20:13:00 UTC, Seb wrote: On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should I make a bug report about that? Yes please. Hi, you

Re: to auto or not to auto ( in foreach )

On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote: On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote: actually, `foreach (v; rng)` looks like `foreach` is *reusing* *existing* *variable*. most of the time you can put `immutable` or something like that there to note that it is not

Re: Autotesting dub packages with dmd nightly

On Saturday, 16 July 2016 at 20:34:49 UTC, Sebastiaan Koppe wrote: Just to let you guys know - and to be sure no one is doing the same - I decided to go ahead and *start* writing an autotester that will fetch dmd nightly and unittest each dub package. It will be using a classic master-worker

Re: Vision for the D language - stabilizing complexity?

On Sunday, 17 July 2016 at 05:14:57 UTC, Walter Bright wrote: On 7/16/2016 7:17 PM, Andrew Godfrey wrote: I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and

Re: to auto or not to auto ( in foreach )

On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote: Chipping in my agreement. foreach(x; y) makes as much syntactic sense as for(x = 0; x < y; x++) where x was not previously defined. One does not expect something that does not look like every other variable definition in the language to

Re: Vision for the D language - stabilizing complexity?

On Saturday, 16 July 2016 at 21:52:02 UTC, Walter Bright wrote: On 7/16/2016 5:32 AM, Andrew Godfrey wrote: [...] Thanks for taking the time to post about your experience with it. Comparing D with SAL is a worthwhile exercise. [...] I've seen SAL before, but have not studied it. My

Re: Vision for the D language - stabilizing complexity?

On Sunday, 17 July 2016 at 02:07:19 UTC, pineapple wrote: On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote: 2) I wonder if an "uninitialized" feature would be worthwhile. That is, a value you can initialize a variable to, equal to 'init', but that static analyzers know you don't

Re: Vision for the D language - stabilizing complexity?

On 7/16/2016 7:17 PM, Andrew Godfrey wrote: I'm more interested in engaging on "in how many years will the D leadership be interested in engaging on the topic of D3?" I feel this is a significant omission from the vision doc, and that omission inflames a lot of the recurring animosity I see on

Re: Vision for the D language - stabilizing complexity?

On Saturday, 16 July 2016 at 21:35:41 UTC, Walter Bright wrote: On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a

Re: to auto or not to auto ( in foreach )

On Sunday, 17 July 2016 at 02:04:50 UTC, Adam D. Ruppe wrote: (x) => x; // defines a new variable foreach isn't alone. compiler should allow `auto` here too.

Re: Vision for the D language - stabilizing complexity?

On 7/16/2016 7:03 PM, Andrew Godfrey wrote: I'm thinking: 1) Static analysis tools still have relevance even in D code. I agree, but their utility is greatly reduced, meaning the payback for the effort makes for a small benefit/cost ratio. 2) I wonder if an "uninitialized" feature would

Re: Vision for the D language - stabilizing complexity?

On 7/15/2016 11:28 PM, Shachar Shemesh wrote: First of all, it sounds like you envision that everyone will solely be using the D supplied allocators, and no one will be writing their own. There won't be anything stopping anyone from writing their own allocators, just like there's nothing

Re: [OT] Re: Card on fire

On Saturday, 16 July 2016 at 07:57:20 UTC, Basile B. wrote: On Friday, 15 July 2016 at 21:03:28 UTC, Ali Çehreli wrote: On 07/14/2016 09:18 PM, Basile B. wrote: > [...] >> [...] posting that. >> [...] "under-appreciated >> [...] > [...] treasures" of > [...] think that you > [...] were truely

Re: Vision for the D language - stabilizing complexity?

On 7/15/2016 11:04 PM, Andrew Godfrey wrote: Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar was talking about @safe code specifically. I can't wrap my mind around wanting a "logical const" feature usable in @safe context; you could already use @system for those

Re: Template args

On Saturday, 16 July 2016 at 00:29:12 UTC, Max Klimov wrote: On Friday, 15 July 2016 at 23:07:20 UTC, Andrey wrote: Hi guys! Can any one tell me - how to pass an array of int's in to the template struct at compile-time, and how to use int there? Like this:

Re: Vision for the D language - stabilizing complexity?

On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote: On 7/14/2016 6:26 AM, Chris wrote: Now, now. Where's your sense of humor? The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all

Re: Card on fire

On 16/07/2016 01:02, Walter Bright wrote: The Ubuntu printer install isn't any better than Microsoft's. I wonder what it is about printers. I can plug in USB drives, internal drives, all sorts of things, and they just work. Even when it's working, the simplest things fail. I learned to never

Re: [OT] Re: Card on fire

On Friday, 15 July 2016 at 21:03:28 UTC, Ali Çehreli wrote: On 07/14/2016 09:18 PM, Basile B. wrote: > [...] >> [...] posting that. >> [...] "under-appreciated >> [...] > [...] treasures" of > [...] think that you > [...] were truely > [...] I was too young to appreciate at the time but

Re: Vision for the D language - stabilizing complexity?

On Saturday, 16 July 2016 at 04:24:39 UTC, Walter Bright wrote: On 7/15/2016 8:25 PM, Andrew Godfrey wrote: I agree and I like mechanically checkable things. But I also like compiler features that mix mechanical checking with the ability to attest to something that can't be mechanically

Re: Vision for the D language - stabilizing complexity?

On 16/07/16 07:24, Walter Bright wrote: Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here. That is something without which none of your arguments made sense to me. Thank you for your clarification. So, would you say you shouldn't use D

Re: Go's march to low-latency GC

On Thursday, 14 July 2016 at 10:58:47 UTC, Istvan Dobos wrote: I was thinking, okay, so D's GC seems to turned out not that great. But how about the idea of transplanting Rust's ownership system instead of trying to make the GC better? This requires drastically changing 99% of the language

Re: [OT] Windows install

On Saturday, 16 July 2016 at 05:26:56 UTC, Walter Bright wrote: On 7/15/2016 9:30 PM, Joakim wrote: As for printing, you're still printing? I think I've printed maybe three or four times in the last decade, but then I almost never read anything on paper during that time either. Sometimes I

Re: Vision for the D language - stabilizing complexity?

On Friday, 15 July 2016 at 09:29:27 UTC, Kagamin wrote: On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad wrote: And please note that this horrible excuse is propagate in the C++ community too. Time and time again people claim that C++ is complex, but it has to be like that in

Re: Card on fire

On Saturday, 16 July 2016 at 04:54:02 UTC, H. S. Teoh wrote: On Fri, Jul 15, 2016 at 05:02:55PM -0700, Walter Bright via Digitalmars-d wrote: On 7/15/2016 3:43 PM, H. S. Teoh via Digitalmars-d wrote: > One of the many reasons I gave up on Windows many years ago, > and never looked back. ;-)

Re: Vision for the D language - stabilizing complexity?

On 16/07/16 02:04, Walter Bright wrote: On 7/15/2016 1:58 PM, Shachar Shemesh wrote: Do enlighten me how to use intrusive reference counting in D. I am quite interested in the answer. Andrei and I are working on it. As he's expressed elsewhere, the idea is to maintain the reference count in

Re: Vision for the D language - stabilizing complexity?

On 7/15/2016 11:12 PM, Shachar Shemesh wrote: So, would you say you shouldn't use D unless all of your code is @safe? Most? Some? None? The idea is to minimize the use of @system. If you've got a large team and large codebase, the use of @system should merit special attention in code

Re: Iterate through getOverloads trait

On 07/15/2016 03:58 PM, Max Klimov wrote: > I'm wondering how I can use the output of __traits(getOverloads, a, > "name"). Apparently, it produces a delegate of calling name() on 'a'. > The example in the doc uses direct indexing (like > __traits(getOverloads, a, "name")[0](param)) and it

Re: [OT] Re: Card on fire

On 07/16/2016 12:57 AM, Basile B. wrote: > On Friday, 15 July 2016 at 21:03:28 UTC, Ali Çehreli wrote: >> The amazing group Replikas > From the few I know i retain this one > > https://youtu.be/Fn8ZfjBsrng?t=23m19s > > very hooking. Amazing! And there is a connection: I recognized "Taş

Re: [OT] Re: Card on fire

On Saturday, 16 July 2016 at 12:16:48 UTC, Ali Çehreli wrote: On 07/16/2016 12:57 AM, Basile B. wrote: > On Friday, 15 July 2016 at 21:03:28 UTC, Ali Çehreli wrote: >> The amazing group Replikas > From the few I know i retain this one > > https://youtu.be/Fn8ZfjBsrng?t=23m19s > > very

[Issue 16285] IAllocator crash

https://issues.dlang.org/show_bug.cgi?id=16285 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com

Re: Export GC Usage Statistics on Request for Profiling

On 2016-07-15 21:39, tcak wrote: Never used D on Xcode, nor I knew it was possible. Well, when it comes to using the debugger in Xcode or profiling using Instruments both can load any application. Although you won't get any demangling in the debugger but if you and the source files to an

build a subpackage in dub?

Say I have a package called "main" and a sub-package in a "complicatedexample" directory, and my dub.json in "main" looks sort of like: "subPackages": [ "./complicatedexample/" ], Let's say I do *not* have ":complicatedexample" in my dependencies for "main", but "complicatedexample" itself

Re: Card on fire

On 2016-07-16 02:06, Walter Bright wrote: BTW, even if an app requires all sorts of registry settings, that is still no excuse. Have a config file, and when the app starts up, it looks for the registry settings. If not there, it reads the config file, and sets the registry settings. I.e. it

@nogc vs IAllocator

Background: working on a replacement for std.xml. Designing the DOM API. Of course, I have to provide a way for the users to use a custom allocator for the DOM objects. But the DOM, as described in the official docs[1] (and as I would like to have it), shall be pluggable: many

Re: @nogc vs IAllocator

I have no idea why anyone would prefer IAllocator approach to efficient and inline-able template based version. I doubt template bloat from dozens of different allocators in one project is realistic concern for std.xml

Re: @nogc vs IAllocator

On Saturday, 16 July 2016 at 18:34:31 UTC, Dicebot wrote: What kind of features do you mean? I'd personally want only compile-time configuration and minimal to no OOP. Thank you for your time. The DOM specification provides "DOM features"[1] as a mean to extend the DOM with custom

Re: extern (C++) including bodies of member functions?

On 2016-07-16 04:01, cy wrote: So, it applies to member functions too (for C++)? Just as if you passed an extern(C++) directive to each one? And only their signature/mangling is changed, so that say in gdb for instance, they represent Type::member instead of zzTypezdxqdstuffmember? Yes. It's

Re: DIP1001: Exception Handling Extensions

On Saturday, 16 July 2016 at 12:42:49 UTC, Andrei Alexandrescu wrote: Work much appreciated. Looks like the new community process works! -- Andrei I'm not sure you understand, I rejected my own PR.

Re: @nogc vs IAllocator

What kind of features do you mean? I'd personally want only compile-time configuration and minimal to no OOP.

Re: @nogc vs IAllocator

And of course I forgot to link the relevant documentation... [1] https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html I have no idea why anyone would prefer IAllocator approach to efficient and inline-able template based version. I doubt template bloat from dozens of different

Re: UDAs on enum members

On Thursday, 14 July 2016 at 07:05:08 UTC, Jacob Carlborg wrote: On 2016-07-13 13:57, Tomer Filiba wrote: It would be really nice if I could put UDAs on enum members as well, e.g., I think it should be supported, if nothing else for "turtles all the way"/completeness. I agree. Another

[Issue 16285] New: IAllocator crash

https://issues.dlang.org/show_bug.cgi?id=16285 Issue ID: 16285 Summary: IAllocator crash Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: normal Priority: P1

Re: Allocator troubles

On Friday, 15 July 2016 at 18:44:26 UTC, Luís Marques wrote: I'm not having success trying to use the allocator API. What am doing wrong here? (OS X, 64-bit) [...] Given the lack of feedback, I'm going to assume it's a bug. https://issues.dlang.org/show_bug.cgi?id=16285

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: .. but why? because. i've lost that fight too.

Re: DIP1001: Exception Handling Extensions

On 07/16/2016 12:51 AM, Superstar64 wrote: On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md I decided to close the PR. The my proposal had too many

Re: Vision for the D language - stabilizing complexity?

On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote: But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I work on Microsoft Word. I'm not sure how much I can share about internal verification tools, but I can say: We do have

Re: Allocator troubles

On Friday, 15 July 2016 at 18:44:26 UTC, Luís Marques wrote: I'm not having success trying to use the allocator API. void main() { [...] enforce(alloc.make!int !is null); enforce(alloc.deallocateAll()); enforce(alloc.make!int !is null);

Re: Allocator troubles

On 07/16/2016 10:23 AM, Luís Marques wrote: On Friday, 15 July 2016 at 18:44:26 UTC, Luís Marques wrote: I'm not having success trying to use the allocator API. What am doing wrong here? (OS X, 64-bit) [...] Given the lack of feedback, I'm going to assume it's a bug.

Re: Allocator troubles

On 07/16/2016 12:07 PM, Andrei Alexandrescu wrote: On 07/16/2016 10:23 AM, Luís Marques wrote: On Friday, 15 July 2016 at 18:44:26 UTC, Luís Marques wrote: I'm not having success trying to use the allocator API. What am doing wrong here? (OS X, 64-bit) [...] Given the lack of feedback, I'm

Re: Allocator troubles

On Saturday, 16 July 2016 at 16:19:11 UTC, Andrei Alexandrescu wrote: Found the problem. Currently allocatorObject allocates the CAllocatorImpl object (interface implementation) straight inside the given allocator, in an ouroboros fashion. Subsequently, deallocateAll deallocates he

Re: Vision for the D language - stabilizing complexity?

On 7/16/2016 6:09 AM, Andrew Godfrey wrote: Walter called Prolog "singularly useless". You have been referring to changes that would amount to a new major version of D as "a cleanup". From the forums, my sense is that there IS a groundswell of opinion, that D2 has some major mistakes in it that

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 20:00:39 UTC, Seb wrote: On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 21:39:42 UTC, cym13 wrote: A variable definition in a foreach -> A variable definition *with auto* in a foreach

Re: What is the current progress on "Safety and Memory Management"?

On Saturday, 16 July 2016 at 20:38:05 UTC, The D dude wrote: On Friday, 15 July 2016 at 12:59:39 UTC, maik klein wrote: https://wiki.dlang.org/Vision/2016H2 Safety and Memory Management Safety and making the GC optional remain important concerns through the end of this year. We are putting

Re: Vision for the D language - stabilizing complexity?

On 7/16/2016 5:32 AM, Andrew Godfrey wrote: On Saturday, 16 July 2016 at 06:40:31 UTC, Walter Bright wrote: But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I work on Microsoft Word. I'm not sure how much I can share about internal

Re: What is the current progress on "Safety and Memory Management"?

On Saturday, 16 July 2016 at 21:45:17 UTC, maik klein wrote: I was actually thinking of contributing something bigger as part of my bachelor thesis. (Not sure if I am allowed to do that) What I wanted to do is to translate a big part of Rust's std to D. Stuff like Rc, Arc, Box, Optional +

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 21:39:42 UTC, cym13 wrote: However auto should be allowed here. You are defining a variable and the fact that it's in a foreach shouldn't be of any importance. The language should enforce orthogonality of orthogonal things, not break it. A variable definition in a

Re: unittests not being run

On Friday, 15 July 2016 at 11:59:51 UTC, Bahman Movaqar wrote: On 07/15/2016 04:16 PM, Jerry wrote: Unittests have to be inside a module to be run on DMD atleast. So putting module foo at top should fix it. Strange. Still not getting picked up. $ dmd --version DMD64 D Compiler

Re: Problems with -fPIC, libraries and exceptions (in linux?)

On Friday, 15 July 2016 at 08:40:02 UTC, Arafel wrote: Just as a follow-up, I think it's looking more and more like a compiler bug. It works properly both with gdc and ldmd2. Should I make a bug report about that? Yes please.

Re: Type constructor with new size

On Friday, 15 July 2016 at 01:10:09 UTC, Eppason wrote: How can I create a new type NT from type T that such that NT is compatible with T when reduced to the size of T, but has size n? Another way to see it is that I would like to construct a type at compile time that has the same layout as

Re: cant run unittests

On Thursday, 14 July 2016 at 10:13:38 UTC, dom wrote: On Thursday, 14 July 2016 at 00:33:50 UTC, ethgeh wrote: On Wednesday, 13 July 2016 at 19:41:53 UTC, dom wrote: how can i run my unittests for a dynamic library? some weird conflict is reported between main functions, my project doesnt

Re: Some asm help for the 'thiscall' calling convention?

On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course,

Autotesting dub packages with dmd nightly

Just to let you guys know - and to be sure no one is doing the same - I decided to go ahead and *start* writing an autotester that will fetch dmd nightly and unittest each dub package. It will be using a classic master-worker architecture and will leverage docker containers. I am aiming

Re: What is the current progress on "Safety and Memory Management"?

On Friday, 15 July 2016 at 12:59:39 UTC, maik klein wrote: https://wiki.dlang.org/Vision/2016H2 Safety and Memory Management Safety and making the GC optional remain important concerns through the end of this year. We are putting them together because the GC alternatives we endorse must

Re: Some asm help for the 'thiscall' calling convention?

On Thursday, 14 July 2016 at 00:51:16 UTC, ethgeh wrote: On Wednesday, 13 July 2016 at 23:06:44 UTC, flamencofantasy wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: On Wednesday, 13 July 2016 at 22:09:05 UTC, flamencofantasy wrote: On Wednesday, 13 July 2016 at 20:39:00

Re: Why modules is so strongly limited?

On Friday, 15 July 2016 at 20:49:05 UTC, imbaFireFenix wrote: On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote: Java does basically the same thing (though they take it even farther, since they only allow one, public class per module), and IIRC, a number of other languages do

Re: Go's march to low-latency GC

On Saturday, 16 July 2016 at 11:02:00 UTC, thedeemon wrote: On Thursday, 14 July 2016 at 10:58:47 UTC, Istvan Dobos wrote: I was thinking, okay, so D's GC seems to turned out not that great. But how about the idea of transplanting Rust's ownership system instead of trying to make the GC

Re: @nogc vs IAllocator

On Saturday, 16 July 2016 at 17:46:12 UTC, Lodovico Giaretta wrote: Background: working on a replacement for std.xml. Designing the DOM API. [...] Another problem that you soon will encounter is that your templated can never be @safe, nothrow or pure again - even if you use the GCAllocator

Re: Some asm help for the 'thiscall' calling convention?

On Thursday, 14 July 2016 at 14:01:29 UTC, Kagamin wrote: On Wednesday, 13 July 2016 at 22:30:51 UTC, Adam Sansier wrote: Um, no, I revived it so that people searching for answers wouldn't be led astray by idiots who pretend to know everything. My word is not COM specification of course,

Re: Vision for the D language - stabilizing complexity?

On Saturday, 16 July 2016 at 07:14:03 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote: On 7/14/2016 6:26 AM, Chris wrote: Now, now. Where's your sense of humor? The thing is, he's just here to troll us. His posts all follow the same pattern of

to auto or not to auto ( in foreach )

foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why?

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? `Note: The ForeachTypeAttribute is implicit, and when a type is not specified, it is inferred. In that

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? Arbitrary limitation. If you want to say how surprising and uselessly limiting it is wait at the end of the

Re: @nogc vs IAllocator

Oops, this looks like dark side of XML spec I wish I have never learned about :X Sorry for irrelevant comment.

Re: UDAs on enum members

Am 16.07.2016 um 20:57 schrieb ZombineDev: On Thursday, 14 July 2016 at 07:05:08 UTC, Jacob Carlborg wrote: On 2016-07-13 13:57, Tomer Filiba wrote: It would be really nice if I could put UDAs on enum members as well, e.g., I think it should be supported, if nothing else for "turtles all the

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote: foreach(auto v; msg) writeln(v); gives an error that a basic type is expected foreach(v; msg) writeln(v); works .. but why? Arbitrary limitation. If you want to say how

Re: to auto or not to auto ( in foreach )

On Saturday, 16 July 2016 at 20:00:39 UTC, Seb wrote: On Saturday, 16 July 2016 at 14:11:34 UTC, cym13 wrote: [...] It's not arbitrary. It keeps the language simple and easy to read. After all the entire auto keyword is just there, because the compiler needs a keyword and in loops it's