Re: Fiber based UI-Toolkit

On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote: On 2017-07-09 23:12, bauss wrote: I believe OSX (possibly macOS too.) only allows it from the main thread. Yes, that's correct. But what's the difference between OSX and macOS ;) Well besides that it's newer versions of the

[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation

https://issues.dlang.org/show_bug.cgi?id=17632 Walter Bright changed: What|Removed |Added Keywords||ice

Re: Fiber based UI-Toolkit

On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote: On 2017-07-10 15:37, Gerald wrote: Having said that, I'm in the camp where this doesn't make much sense. Using fibers on the main UI thread is likely going to result in a blocked UI whenever a fiber takes too long to do its work.

Re: Why no offsetof for static struct?

On 7/11/2017 6:14 AM, FoxyBrown wrote: On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote: No, it isn't. Static members are stored in an entirely different place than non-static members. They are really just global variables in memory with their in-source name being nested

Re: Debugging D applications from VS code with webfreak.debug

On Friday, 24 February 2017 at 13:19:53 UTC, FR wrote: On Friday, 24 February 2017 at 03:15:11 UTC, Jerry wrote: You can use the C++ plugin, which provides a debugger. Just make sure you aren't using optlink, I don't think it generates compatible files. Also you might need to use "-gc" which

Re: Translating C macros to D

On Monday, 10 July 2017 at 19:42:28 UTC, Jacob Carlborg wrote: I'm trying to come up with a generic way to translate function like C macros to D to be used in DStep. [...] Is not getting rid of the macro an option? By that I mean translating the code inside the macro (which can admitedly be

stacktrace for InvalidMemoryOperationError

Hi! I have vibe.d application and long-standing error in it. For the current moment, I have logs for stdout, stderr, and additional log to write exceptions I catch. This error gives me only the short line in stderr log: core.exception.InvalidMemoryOperationError@src/core/exception.d(696):

Re: dmd and Archlinux

Am Sun, 09 Jul 2017 18:35:09 + schrieb Antonio Corbi : > Hi! > > Are there any news about the status of packaging dmd for > archlinux? > > The last dmd compiler packaged is 2.074.0 and since the last > batch of updated packages in archlinux, dmd generated objects >

Re: Types: The Next Generation (Was: Why is phobos so wack?)

Am Sun, 9 Jul 2017 16:22:16 -0400 schrieb "Nick Sabalausky (Abscissa)" : > […] a sufficiently-smart compiler could conceivably even > choose "runtime" vs "compile-time" (or even, "it varies") > based on optimization priorities. GCC already does this, i.e.

Re: .NET Library In D

On Mon, 10 Jul 2017 21:36:05 +, FoxyBrown wrote: > The goal is that, one day, we can effectively replace the phobos with > .NET semantics if we want. It, being a nicer library, and all the source > code available through reflection, makes it a nice target. While the > source code cannot be

Re: Call for arms: Arch Linux D package maintenance

On Sun, 09 Jul 2017 21:33:15 +, bachmeier wrote: > The answer (assuming things are still run the way they > were back then) is that you're not able to do anything about it. You > won't see anything done with the official package and you won't be able > to put anything in AUR because there is

Re: proposed @noreturn attribute

Am Sat, 8 Jul 2017 03:15:39 -0700 schrieb Walter Bright : > […] > > Having an @noreturn attribute will take care of that: > > @noreturn void ThisFunctionExits(); > > Yes, it's another builtin attribute and attributes are arguably a failure in > language design.

Re: Cannot dup an associative array but why?

On Monday, 10 July 2017 at 19:11:37 UTC, Ali Çehreli wrote: On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote: > Is there something special about ClassInfo that confuses? Look at this > example: > > struct Foo > { > > } > > class Bar > { > } > > void main() > { > Foo*[Bar] a; > auto aa = a.dup;

[Issue 10233] [Tracker] Grammar issues

https://issues.dlang.org/show_bug.cgi?id=10233 Issue 10233 depends on issue 953, which changed state. Issue 953 Summary: Multiple C style declarations of same type cannot be in one statement https://issues.dlang.org/show_bug.cgi?id=953 What|Removed |Added

[Issue 12196] Bad error message for multiple declarations

https://issues.dlang.org/show_bug.cgi?id=12196 Vladimir Panteleev changed: What|Removed |Added Resolution|WORKSFORME

[Issue 953] Multiple C style declarations of same type cannot be in one statement

https://issues.dlang.org/show_bug.cgi?id=953 Vladimir Panteleev changed: What|Removed |Added Status|REOPENED

[Issue 953] Multiple C style declarations of same type cannot be in one statement

https://issues.dlang.org/show_bug.cgi?id=953 --- Comment #9 from Vladimir Panteleev --- *** Issue 12196 has been marked as a duplicate of this issue. *** --

Re: version=D_16

On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote: The problem Walter pointed to is that due to integer promotion, arithmetic operands of types smaller than int are converted to int, hence even if you use bytes and shorts you would end up using ints, which are expensive

[Issue 4085] Steps toward a static foreach

https://issues.dlang.org/show_bug.cgi?id=4085 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 17628] formattedWrite is impure on double

https://issues.dlang.org/show_bug.cgi?id=17628 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

Re: version=D_16

On Monday, 10 July 2017 at 21:53:16 UTC, Luís Marques wrote: On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote: You can't use RTTI or Exceptions, for example. Those generate bloat even if they are not used - a compiler switch is typical to disable them. It's not true that C++ is

[Issue 15770] SocketSet.add OutOfMemoryError on Posix

https://issues.dlang.org/show_bug.cgi?id=15770 Vladimir Panteleev changed: What|Removed |Added Status|NEW

[Issue 17633] Unary negation has the wrong type

https://issues.dlang.org/show_bug.cgi?id=17633 Vladimir Panteleev changed: What|Removed |Added Component|dlang.org |dmd

[Issue 7063] No error or warning for conflicting D and C symbols

https://issues.dlang.org/show_bug.cgi?id=7063 --- Comment #5 from Vladimir Panteleev --- (In reply to anonymous4 from comment #4) > This can be reliably diagnosed only by the linker, since duplicate symbols > can be buried in libraries or come from different

[Issue 17631] Can overload functions with simple enum argument, but not with complex enum argument

https://issues.dlang.org/show_bug.cgi?id=17631 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

https://issues.dlang.org/show_bug.cgi?id=17596 --- Comment #7 from Vladimir Panteleev --- (In reply to Cy Schubert from comment #5) > What do you think if DMD D and LDC D provided a facility to test > __FreeBSD_version or if not that the major.minor version

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

On Monday, 10 July 2017 at 20:10:58 UTC, 12345swordy wrote: On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote: On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote: On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote: I have submitted a bug report regarding this:

Re: Automatic invariant generation

On Monday, July 10, 2017 11:26:43 AM MDT Walter Bright via Digitalmars-d wrote: > On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote: > > For some assertions, having more than a file and line number is nice > > (e.g. if you have messages for your pre-condition assertions, then you > >

Re: version=D_16

On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote: You can't use RTTI or Exceptions, for example. Those generate bloat even if they are not used - a compiler switch is typical to disable them. It's not true that C++ is "pay only for what you use". If the C++ usage is "C with

Re: Why no offsetof for static struct?

On 07/10/2017 02:14 PM, FoxyBrown wrote: > On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote: >> On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote: >>> Cannot get the offset of static members of a struct >> >> That's because static members do not have an offset. They are not

.NET Library In D

I was able to get my C# to D convert to convert about 25% of the .net library v4.6 It converts the following libs: // System.CodeDom // System.CodeDom.Compiler // System.Collections.Concurrent // System.Collections.Generic // System.Collections.ObjectModel // System.Collections.Specialized //

[Issue 17633] Unary negation has the wrong type

https://issues.dlang.org/show_bug.cgi?id=17633 --- Comment #1 from Eyal --- If C's rules are not desirable here. That's fine. assert_minus_1 should STILL not fail. instead of -ubyte becoming int as in C, -ubyte can at least become byte. --

Re: version=D_16

On 7/10/2017 1:52 PM, Luís Marques wrote: On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote: On 7/10/2017 12:46 PM, Luís Marques wrote: I'm curious how that implementation addresses the issues I brought up: I'm not really sure how to respond, you mostly just made statements about

[Issue 17628] formattedWrite is impure on double

https://issues.dlang.org/show_bug.cgi?id=17628 --- Comment #1 from Vladimir Panteleev --- Missing: import std.array : appender; Seems to be impure because it calls snprintf (which I think may change FPU flags or something). --

.NET Library In D

I was able to get my C# to D convert to convert about 25% of the .net library v4.6 It converts the following libs: // System.CodeDom // System.CodeDom.Compiler // System.Collections.Concurrent // System.Collections.Generic // System.Collections.ObjectModel // System.Collections.Specialized //

[Issue 17627] DMD's toChars should not include the entire array of a slice result

https://issues.dlang.org/show_bug.cgi?id=17627 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 17633] New: Unary negation has the wrong type

https://issues.dlang.org/show_bug.cgi?id=17633 Issue ID: 17633 Summary: Unary negation has the wrong type Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW

[Issue 17626] Same name variable assignment should raise a compile-time warning

https://issues.dlang.org/show_bug.cgi?id=17626 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

https://issues.dlang.org/show_bug.cgi?id=16650 --- Comment #6 from Vladimir Panteleev --- (In reply to Jacob Carlborg from comment #5) > I didn't really expect it to work. Perhaps a worthwhile feature? Perhaps! Feel free to file an enhancement request. --

[Issue 17625] Confusing error message for private functions in different modules

https://issues.dlang.org/show_bug.cgi?id=17625 Vladimir Panteleev changed: What|Removed |Added Keywords|

Re: LDC 1.3.0

On Sunday, 9 July 2017 at 21:33:17 UTC, kinke wrote: LDC 1.3.0, the LLVM-based D compiler, is available for download! This release is based on the 2.073.2 frontend and standard library and supports LLVM 3.5-4.0. Congratulations all! :-) The ldc2 snap package has been updated to 1.3.0 as

Re: Why no offsetof for static struct?

On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote: On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote: Cannot get the offset of static members of a struct That's because static members do not have an offset. They are not part of the struct in memory, just in name. We can

[Issue 17614] [REG2.075.0-b2] __VERSION__ has the wrong value

https://issues.dlang.org/show_bug.cgi?id=17614 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/installer https://github.com/dlang/installer/commit/5a92cda46371382ff03276970dd970d1a9718851 fix Issue 17614 - __VERSION__ has the wrong value

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

NoBigDeal256 wrote: Do you happen to have a link to the bug report for this specific issue that I could look at? I looked at the known bugs list and couldn't find anything related to this. nope. it is a kind of "known bug nobody bothered to report". ;-)

Re: version=D_16

On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote: On 7/10/2017 12:46 PM, Luís Marques wrote: I'm curious how that implementation addresses the issues I brought up: I'm not really sure how to respond, you mostly just made statements about your worldview. For instance: "C++ on a

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

On Monday, 10 July 2017 at 20:31:12 UTC, ketmar wrote: NoBigDeal256 wrote: I'm currently learning D and started working on one of my first projects which is an API wrapper. I'm currently having an issue with my program getting a InvalidMemoryOperationError upon exiting the process on Windows

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On 7/10/2017 12:53 PM, Luís Marques wrote: On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote: What is the goal/reason/rationale for making a 16 bit D target? - I program for MSP430 - I'm tired of C's limitation - LDC works with MSP430 Those are quite understandable goals. I'm

Re: Slides share: DMesos - Not only a re-implementation of Mesos

On Monday, 10 July 2017 at 17:29:01 UTC, 鲜卑拓跋枫 wrote: Dear all, I am a D-language amateur from China, and just want to share you with a slides from me that post on MesosCon Asia 2017(Beijing):

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On 7/10/17 10:49 AM, Luís Marques via Digitalmars-d wrote: On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote: The official stance is that we don't. There is just far too much baggage that gets piled in by default that makes it very hostile, however those of us who are capable of

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

NoBigDeal256 wrote: I'm currently learning D and started working on one of my first projects which is an API wrapper. I'm currently having an issue with my program getting a InvalidMemoryOperationError upon exiting the process on Windows 7. On my Debian VM I get a segmentation fault. known

Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

Still haven't figured out what's wrong. Any help would be appreciated.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote: Oh, I didn't mean to imply that I wouldn't love to have it in D (assuming it was all well-fleshed out and didn't have big problems). I just wanted to be crystal clear that I'm merely discussing a langauge design idea here rather than

Re: version=D_16

On 7/10/2017 12:46 PM, Luís Marques wrote: since LDC essentially works for MSP430, even though it isn't officially supported. I'm curious how that implementation addresses the issues I brought up:

Why no offsetof for static struct?

Cannot get the offset of static members of a struct struct X { __gshared public: int x; } X.x.offsetof < invalid. We can clearly get a pointer to the static struct X since is effectively the address of X(regardless nomenclature and terminology issues in D trying to hide this).

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 07/10/2017 02:55 PM, Jacob Carlborg wrote: On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote: The other important thing I want to emplasize yet again (just in case, because I know from experience in the past it's exactly this kind of point that rarely gets noticed), I'm not proposing D

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote: On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote: On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote: I have submitted a bug report regarding this: https://issues.dlang.org/show_bug.cgi?id=17592 This is IMO

Re: Why no offsetof for static struct?

On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote: Cannot get the offset of static members of a struct That's because static members do not have an offset. They are not part of the struct in memory, just in name. We can clearly get a pointer to the static struct X There's barely

Re: proposed @noreturn attribute

On 7/10/2017 12:02 PM, Jacob Carlborg wrote: Are those few cases worth optimizing for? Yes. Not having it makes enforce(), for example, generate poor code.

Re: proposed @noreturn attribute

On 7/10/17 3:05 PM, Meta wrote: On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote: On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is

Foreign threads in D code.

Hello! I have written some D code that I need to link to :C++ huge project. Let it be just one function that uses GC. The question is: if C++ code creates several threads and runs this :D function simultaneously, will GC work correctly? p.s. Of course the druntime is initialized before it.

Why no offsetof for static struct?

Cannot get the offset of static members of a struct struct X { __gshared public: int x; } X.x.offsetof < invalid. We can clearly get a pointer to the static struct X since is effectively the address of X(regardless nomenclature and terminology issues in D trying to hide this).

Re: proposed @noreturn attribute

On 7/10/2017 12:05 PM, Meta wrote: Currently not. This is either a bug or the compiler's flow analysis is not robust enough to detect this case. Flow analysis relies on the function's signature, not its implementation, and currently the signature contains no information about noreturn.

Re: proposed @noreturn attribute

Jacob Carlborg wrote: I'm going to ask the stupid question: I understand that this is for the compiler to generate better code. But, since the attribute (or whatever it is) indicates that a function won't return, it can only be used in very few cases. Are those few cases worth optimizing for?

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On Monday, 10 July 2017 at 19:41:48 UTC, Walter Bright wrote: What is the goal/reason/rationale for making a 16 bit D target? - I program for MSP430 - I'm tired of C's limitation - LDC works with MSP430

Re: Translating C macros to D

Jacob Carlborg wrote: Does anyone have any other ideas that would work for everything that can be passed to a C macro? string mixin with concatenation. this is basically what C macro is anyway.

version=D_16

Hello, Johan Engelen suggested I bring further attention to this issue here in the D forums. We need a version identifier for 16-bit code (e.g. to conditionally define size_t correctly). This is not theoretical, it's an actual need, since LDC essentially works for MSP430, even though it

[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation

https://issues.dlang.org/show_bug.cgi?id=17632 Vladimir Panteleev changed: What|Removed |Added Keywords|

Translating C macros to D

I'm trying to come up with a generic way to translate function like C macros to D to be used in DStep. One problem with macros is that it's not possible, by just looking at the macro, to understand how it's used, what can be passed to it. For example, it's possible to pass values, variables

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On 7/10/2017 5:41 AM, Luís Marques wrote: for 16 bit targets Having developed C/C++ on 16 bit targets for a couple decades, I have some curmudgeonly perspective. 1. having __LINE__ as size_t is madness. If I was responsible for that, shame on me. 2. a 16 bit type for 16 bit targets is

Re: Slides share: DMesos - Not only a re-implementation of Mesos

On Monday, 10 July 2017 at 18:45:34 UTC, Nick Sabalausky (Abscissa) wrote: On 07/10/2017 02:16 PM, Joakim wrote: I'm actually skeptical of cloud- I think mobile p2p will eat most of the cloud- I've been REALLY hoping p2p will eat...cloud^H^H^H^H^Hcentralized internet services[1], but if I

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 18:09:54 UTC, H. S. Teoh wrote: On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: On 07/09/2017 06:51 AM, Daniel N wrote: > On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote: > > On Saturday, 8 July 2017 at 10:15:39 UTC,

Re: Cannot dup an associative array but why?

On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote: > Is there something special about ClassInfo that confuses? Look at this > example: > > struct Foo > { > > } > > class Bar > { > } > > void main() > { > Foo*[Bar] a; > auto aa = a.dup; // OK > Foo*[ClassInfo] b; // Error: static assert

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote: On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow

Re: proposed @noreturn attribute

On 2017-07-08 12:15, Walter Bright wrote: C compilers (and by extension C++ compilers) usually have an extension which allows a function to be marked as one that never returns. The point of this is it enables improved data flow analysis and better code being generated. Noreturn functions crop

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote: Well, the nice thing about this approach (basing a concept-ish system *on top* of existing D-style design-by-introspection, as opposed to a C++-like concepts with no D-like features to complement it), is that it *doesn't* require every

Re: proposed @noreturn attribute

On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow analysis is useful. FunctionThatDoesnotReturn(); a = b; // error:

Re: Slides share: DMesos - Not only a re-implementation of Mesos

On 07/10/2017 02:16 PM, Joakim wrote: I'm actually skeptical of cloud- I think mobile p2p will eat most of the cloud- I've been REALLY hoping p2p will eat...cloud^H^H^H^H^Hcentralized internet services[1], but if I were a betting man I'd bet heavily against it. For one thing, for p2p to kill

Cannot dup an associative array but why?

Is there something special about ClassInfo that confuses? Look at this example: struct Foo { } class Bar { } void main() { Foo*[Bar] a; auto aa = a.dup; // OK Foo*[ClassInfo] b; // Error: static assert "cannot call Foo*[TypeInfo_Class].dup because Foo* is not copyable" auto bb =

Re: iterate over variadic

On 07/10/2017 08:31 PM, H. S. Teoh via Digitalmars-d-learn wrote: if (i % 2) { // even odd ... // do something with arg } else { // odd even

Re: proposed @noreturn attribute

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow analysis is useful. FunctionThatDoesnotReturn(); a = b; // error: unreachable code

[Issue 17632] New: 2.075 beta regression: opBinary and delegate code generation

https://issues.dlang.org/show_bug.cgi?id=17632 Issue ID: 17632 Summary: 2.075 beta regression: opBinary and delegate code generation Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: Automatic invariant generation

On 7/9/2017 4:37 AM, Steven Schveighoffer wrote: On 7/9/17 7:00 AM, Walter Bright wrote: On 7/9/2017 3:37 AM, Steven Schveighoffer wrote: Yet, here is an example of where we have effectively added a null pointer exception. > At the very least, this should be eliminated on Linux and just use

Re: Automatic invariant generation

On 7/9/2017 6:37 PM, Jonathan M Davis via Digitalmars-d wrote: For some assertions, having more than a file and line number is nice (e.g. if you have messages for your pre-condition assertions, then you can make it so that when it fails, the programmer doesn't even need to look at the source

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 07/10/2017 09:16 AM, Martin Nowak wrote: On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky (Abscissa) wrote: SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...} Looks like concepts. We've settled on leveraging the already useful template constraints (at best in CNF [¹]) for

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 07/10/2017 11:58 AM, bpr wrote: You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template

Re: Slides share: DMesos - Not only a re-implementation of Mesos

On Monday, 10 July 2017 at 17:29:01 UTC, 鲜卑拓跋枫 wrote: Dear all, I am a D-language amateur from China, and just want to share you with a slides from me that post on MesosCon Asia 2017(Beijing):

Re: proposed @noreturn attribute

On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 07/09/2017 06:51 AM, Daniel N wrote: > > On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote: > > > On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: > > > > > > > Has anyone a better

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On Monday, 10 July 2017 at 18:03:27 UTC, Steven Schveighoffer wrote: I think it's reasonable to instrument druntime/phobos with line_t, and then libraries may or may not work with 16-bit (I wouldn't be surprised if most don't), but at least they will likely work for files less than 65k lines

Re: DIP 1010--Static foreach--Formal Review

On Monday, 10 July 2017 at 08:53:42 UTC, Mike Parker wrote: As promised, since there has been zero feedback on DIP 1010, "Static foreach", in either the Draft or Preliminary review rounds, I'm going to skip the normal two-week feedback cycle on the Formal review. If there are no major

Re: Is runtime info in shared memory?

On 07/09/2017 02:38 AM, Jean-Louis Leroy wrote: When I look at ldc2's object.d I have the impression it's thread local. I may be wrong though, just beginning to learn about 'shared'. Unless it's marked as shared or __gshared it's thread-local by default. Ali

[Issue 17159] Behavior of unions at compile time is not documented

https://issues.dlang.org/show_bug.cgi?id=17159 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/e6085cb8faa58a8dcf243aacd3bc93f3ac89d8b2 Fix Issue 17159 - Behavior of unions at compile

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On 7/10/17 1:49 PM, Luís Marques wrote: On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote: The official stance is that we don't. There is just far too much baggage that gets piled in by default that makes it very hostile, however those of us who are capable of doing so won't try to

Re: Get a string of a function name from a function pointer?

On 07/10/2017 05:26 AM, SauceKode wrote: > I need to pass a group of (C) function pointers to another language from > D... is there a way to derrive a name from a function pointer? Or do I > have to manually list out the names? libunwind should be able to provide that functionality. Otherwise,

Re: problem overloading functions with complex enum type

On 07/08/2017 08:23 AM, Eric wrote: > enum AS : string[2] { a = ["1","2"], b = ["3","4"] }; > enum BS : string[2] { a = ["5","6"], b = ["7","8"] }; > > void funcs(AS a) { writeln("AS"); } > void funcs(BS b) { writeln("BS"); } > funcs(AS.a); // compiler error: matches both funcs(AS) and

Re: proposed @noreturn attribute

On Mon, Jul 10, 2017 at 03:47:35PM +0200, Jacob Carlborg via Digitalmars-d wrote: > On 2017-07-09 23:14, H. S. Teoh via Digitalmars-d wrote: > > > I like out{ assert(0); } for pretty much the same reasons as Steven > > lists. The biggest pro is that **the language already supports it*. > >

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On 07/10/2017 07:32 AM, Jacob Carlborg wrote: Something like this has been proposed several times before, but Andrei doesn't seem to like it. He think it's a failure that all the conditions need to have a name, or something like that. I prefer your approach. Well, the nice thing about

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote: The official stance is that we don't. There is just far too much baggage that gets piled in by default that makes it very hostile, however those of us who are capable of doing so won't try to stop you, and you have the likes of

Re: Types: The Next Generation (Was: Why is phobos so wack?)

On Monday, 10 July 2017 at 16:16:40 UTC, bpr wrote: On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote: Ah, I guess it is very similar after all, except it'd be based on top of and coexist with all of D's design by introspection stuff (rather than exist without it as with C++),

Re: size_t.sizeof == 2 && __LINE__.sizeof == 4

On 10 July 2017 at 17:56, Luís Marques via Digitalmars-d wrote: > On 10/07/2017 14:31, Jonathan M Davis via Digitalmars-d wrote: >> >> I didn't think that D supported 16-bit targets at all. Do ldc and/or gdc >> support 16-bit targets of some kind? > > > LDC accepts

Slides share: DMesos - Not only a re-implementation of Mesos

Dear all, I am a D-language amateur from China, and just want to share you with a slides from me that post on MesosCon Asia 2017(Beijing): https://mesosconasia2017.sched.com/event/AZc6/dmesos-not-only-a-re-implementation-of-mesos-ce-feng-li-emc# I do really wanna to implement the

  1   2   >