Re: Value Range Propigation Spec

Hi, I am the guy who implemented the (currently incomplete) vrp for sdc. I see vrp as a tool to avoid _unnecessary_ casts. _Not_ as means to avoid _all_ casts. void main(in string[] args) { immutable size_t len = args.length % 10; ubyte x = len; ubyte[] a; foreach (immutable

Re: Value Range Propigation Spec

you are right. I misread the code-snippt above. Of course this is staticly checkable!

Re: 'int' is enough for 'length' to migrate code from x86 to x64

On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote: I thought everyone hated foreach_reverse! I dislike foreach_reverse; 1. it's a keyword with an underscore in it; 2. complicates implementation of foreach and parsing. 3. key_word with under_score

Re: D Meetup in Berlin

Nice! I will have to see if I can make it. BTW. is sociomantic still hiring ?

Re: Do everything in Java…

Unittests are great to avoid regressions. Unitests give confidence. You can do radical changes to your codebase much easier if you know, that nothing breaks because of it. I not a fan of TDD. But I like it that I know directly that there are no regressions.

Which optimisations are are easier or perhaps only possible in the frontend ?

Hello guys, I want to work on optimisations in the semantic analysis stage. Could you chime in with thoughts about what can only be there and not in llvm-ir for example ? Thanks Stefan

Re: No runtime attribute?

On Wednesday, 10 December 2014 at 10:46:58 UTC, bearophile wrote: The #[no_std] attribute is used to avoid the runtime in Rust. Do we have any use for a @noruntime attribute in D? All @noruntime functions are also @nogc (so you don't need to put both attributes). This could give a compilati

Re: Which optimisations are are easier or perhaps only possible in the frontend ?

On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy wrote: DMD's inliner might be a good place to start. There is a lot to be done there. I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently.

Re: Which optimisations are are easier or perhaps only possible in the frontend ?

Could we come back to the topic ? :)

Re: Which optimisations are are easier or perhaps only possible in the frontend ?

On Thursday, 11 December 2014 at 10:59:24 UTC, Daniel Murphy wrote: Why? If the inliner is out because of DMD's merging process, then so is the rest of the frontend. It is not out! But my question was not about dmd specific things, I meant it more generally.

Re: Which optimisations are are easier or perhaps only possible in the frontend ?

On Thursday, 11 December 2014 at 12:20:50 UTC, Manu via Digitalmars-d wrote: I've often thought one of the biggest wins that would seem to affect my code would be comprehensive value range propagation. assert's and contracts can give value range information to the compiler, also comparison state

Re: Which optimisations are are easier or perhaps only possible in the frontend ?

On Friday, 12 December 2014 at 00:20:30 UTC, deadalnix wrote: More generally, you don't want to optimize anything in the frontend: - It is gonna create unscrutable code for debug. - You optimize before inlining, and so won't get the optimization allowed by inlining. You want to add metada

Re: Is anyone working on a D source code formatting tool?

I'm powerful writing a parser-generator, that will be able to transform the generated parse-tree back into source automatically. writing a rule-based formatter should be pretty doable.

Re: Lexical, Syntatic and Semantic Merge of D Source Code

On Saturday, 12 July 2014 at 10:08:35 UTC, Joakim wrote: It's a good idea, something I've thought would be nice before, and a first step towards the Dfix concept Andrei has endorsed: There is something I found a great insperation is coccinelle http://coccinelle.lip6.fr/ it looks like a perf

Re: Using import in map

On Saturday, 31 January 2015 at 19:52:11 UTC, Jacob Carlborg wrote: Is this supposed to work: enum foo = ["foo"].map!((string e) => import(e)); When I compile the above code with 2.066.1 I get the following error: main.d(1): Error: variable e cannot be read at compile time main.d(1): Error:

Re: Renaming DMD File Extensions from C to C++

On Tuesday, 3 February 2015 at 01:33:32 UTC, deadalnix wrote: On Tuesday, 3 February 2015 at 00:59:26 UTC, Andrei Alexandrescu wrote: On 2/2/15 4:23 PM, eles wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C

Re: Last week for DConf 2015 submissions

+1 for the compiler-dev table. I'd be happy to take part on that.

pureity of closures

dmd infers function closures impure if impure functions are defined within them. even if those are never called and can never be accessed outside of the closure. Example : int a; void closure() pure { impure_function() { a++; } } t.d(4): Error: pure function 't.closure.impure_function

Re: pureity of closures

On Sunday, 22 March 2015 at 18:24:31 UTC, ketmar wrote: you can't do anything with `impure_function` anyway. Precisely my point! a perfectly pure function is inferred impure because of dead code!

Re: pureity of closures

On Sunday, 22 March 2015 at 19:06:33 UTC, ketmar wrote: hm. i missed this part (about dead code). compiler doesn't do "dead nested function removal" before semantic analysis, afair, and attribute inference is in semantic stage. yet you can cheat compiler by turning `impure_function()` to temp

Re: pureity of closures

On Sunday, 22 March 2015 at 21:21:59 UTC, ketmar wrote: i believe that both ways is right (i.e. both generating error and not generating error). I am sorry but, this is not an helpful answer. I will stick to my callgraph analysis for now.

Re: pureity of closures

On Monday, 23 March 2015 at 09:45:41 UTC, Dicebot wrote: I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function

Re: pureity of closures

On Friday, 27 March 2015 at 14:29:05 UTC, Shammah Chancellor wrote: Pure functions returning impure functions. *BOOM* My brain just exploded. -Shammah I am not sure when this would happen, but why disallow it ?

Re: pureity of closures

On Friday, 27 March 2015 at 17:47:26 UTC, H. S. Teoh wrote: What I'm more concerned about is whether the current compiler implementation may accidentally allow leakage of the pure function's internal context, which would break purity. T please explain your reasoning with a bit of example cod

Shared - Another Thread

Hi, reading the other shared thread "shared - i need to be useful"(https://forum.dlang.org/thread/mailman.4299.1539629222.29801.digitalmar...@puremagic.com) let me to an important realisation concerning the reason shareding data across threads is so unintuitve and hard to get right. The rea

Re: Shared - Another Thread

On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote: [another person] cannot actually occupy the same space. It is physically impossible. Actually, that's not quite true, If they were to try hard enough the result would be nuclear fusion, (I am guessing (I am not a phsysist)), in

Re: Shared - Another Thread

On Wednesday, 17 October 2018 at 21:40:35 UTC, Stanislav Blinov wrote: Now, I perfectly understand what Manu wants: for `shared` to stop being a stupid keyword that nobody uses, and start bringing in value to the language. At the moment, the compiler happily allows you to write and read `shared

Re: Shared - Another Thread

On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote: Nah, that's not even anywhere close to nuclear fusion. The atoms which make up your body (and basically everything else) are mostly empty, with just a tiny speck of a nucleus, and a bunch of extremely tiny electrons zipping ab

Re: Shared - Another Thread

On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote: On Wed, Oct 17, 2018 at 10:13:37PM +, Stefan Koch via Digitalmars-d wrote: On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote: [...] > But nobody will be building a fusion engine out of race > conditions a

Re: Special Code String for mixins

On Wednesday, 14 March 2018 at 15:50:13 UTC, Jonathan Marler wrote: On Wednesday, 15 March 2017 at 13:50:28 UTC, Inquie wrote: [...] I've got a PR for dmd (https://github.com/dlang/dmd/pull/7988) that implements "interpolated strings" which makes generating code with strings MUCH nicer, i.e.

Re: Tuple DIP

On Thursday, 15 March 2018 at 14:07:12 UTC, JN wrote: On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: As promised [1], I have started setting up a DIP to improve tuple ergonomics in D: https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md I may be out of the loop h

Re: D vs nim

On Tuesday, 27 March 2018 at 12:02:37 UTC, jmh530 wrote: On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: [snip] I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. In the comparison you

Re: #dbugfix Issue 16486 200$

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [1] https://issues.dlang.org/show_bug.cgi?id=16486 Ah that is an interesting bug which further demonstrates that templates are a tricky thing :) Basically you cannot _generally_ proof that one template just forwards to another. Therefore

newCTFE Status March 2018

Hello Guys, I took a few days off over easter and I have very good news for you. The following code will now compile and execute correctly using newCTFE. --- class C { int i() {return 1;} } class D : C { override int i() {return 2;} float f() { return 1.0f; } } class E : D { overrid

Re: __has_side_effects

On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/ Discussion aside, I notice with pleasant surprise gcc has an introspection primitive we didn't think of: __is_constant that (I assume) yields true if the gi

Re: D compiles fast, right? Right??

On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu wrote: On 3/30/18 12:12 PM, Atila Neves wrote: Fast code fast, they said. It'll be fun, they said. Here's a D file:     import std.path; Yep, that's all there is to it. Let's compile it on my laptop:     /tmp % time dmd -c  foo

Re: newCTFE Status March 2018

On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote: On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote: [...] How close are you to finish this? 85 to 90% maybe. I expect that there will many bugs which were hidden by newCTFE not supporting classes, which will now be out i

Re: newCTFE Status March 2018

On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote: On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote: On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote: On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote: [...] How close are you to finish this?

Re: newCTFE Status March 2018

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote: [...] Oh I was not aware people would try this :) I have fixed the build please pull.

Re: newCTFE Status March 2018

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote: [...] What is going on here is that it tries to build the gccjit backend which is currently in a dysfunctional state. I am currently getting trying to get libgccjit working such that I can make use of it's debug output, while I am tr

Re: D compiles fast, right? Right??

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote: On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote: Could be faster. It's been a fair amount of time since somebody has done profiling of dmd. It needs to be done. There's probably plenty of low hanging fruit. Speculating about why i

Re: D compiles fast, right? Right??

On Monday, 2 April 2018 at 12:35:03 UTC, Atila Neves wrote: On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote: On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote: Could be faster. It's been a fair amount of time since somebody has done profiling of dmd. It needs to be done. There's p

Re: std/typecons.d(2010:36)[warn]: Left side of logical or is identical to right side.

On Monday, 2 April 2018 at 16:46:39 UTC, Andrei Alexandrescu wrote: I'm seeing this in the CI runs, but the line is actually not in error: https://github.com/dlang/phobos/blob/master/std/typecons.d#L2010 Where would be the problem? Andrei I guess it's parsed as a comma expression, which wo

Re: D compiles fast, right? Right??

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote: On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote: Could be faster. It's been a fair amount of time since somebody has done profiling of dmd. It needs to be done. There's probably plenty of low hanging fruit. Speculating about why i

Re: D compiles fast, right? Right??

On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote: [ ... ] Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone idle chattaroo in the forums - is where we need to hit. What we have here, ladies and gentlemen, is a high-impact preapproved item

Re: D compiles fast, right? Right??

On Wednesday, 4 April 2018 at 20:04:04 UTC, Jack Stouffer wrote: On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote: Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone idle chattaroo in the forums - is where we need to hit. What we have here,

Re: D compiles fast, right? Right??

On Wednesday, 4 April 2018 at 20:02:56 UTC, Dmitry Olshansky wrote: On Wednesday, 4 April 2018 at 19:25:43 UTC, Stefan Koch wrote: On Wednesday, 4 April 2018 at 01:08:48 UTC, Andrei Alexandrescu wrote: [ ... ] Exactly, which is why I'm insisting this - and not compiler benchmarking, let alone

Re: Deprecating this(this)

On Wednesday, 4 April 2018 at 22:30:39 UTC, Walter Bright wrote: On 4/1/2018 3:49 AM, bachmeier wrote: What I was wondering too. I mean, breaking changes just don't happen to this language. Now there will be, without even an indication of how existing code would have to be rewritten, or how th

newCTFE Status April 2018

Hi Guys, I have just implemented dynamic cast. Or rather I have debugged it. The generated byte-code for dynamic cast itself was correct. However per function only one dynamic cast would be generated. To generate my dynamic casts I loop through my type table and look for classes which are dyna

Re: =void in struct definition

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote: struct S { int a; int[5000] arr = void; } void func() { S s; } During the s initialization, the entire "S" area is initialized, including the member arr which we asked to be = void. Is this a bug? Shachar Not semantica

Re: =void in struct definition

On Monday, 9 April 2018 at 11:15:14 UTC, Stefan Koch wrote: On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote: [ ... ] During the s initialization, the entire "S" area is initialized, including the member arr which we asked to be = void. Is this a bug? Shachar [ ... ] {This c

Re: =void in struct definition

On Monday, 9 April 2018 at 14:11:35 UTC, jmh530 wrote: On Monday, 9 April 2018 at 11:15:14 UTC, Stefan Koch wrote: Not semantically, but you might consider it a performance bug. This particular one could be fixed, put I cannot say how messy the details are. There is potential for code that sil

Re: What are AST Macros?

On Friday, 6 April 2018 at 21:45:45 UTC, Zach Tollen wrote: I think Walter's reason was that such macros would hide too many idiosyncrasies in how they were programmed, such that a lot of code which seems simple on the surface will actually obfuscate complicated and arbitrary macro-programmin

Re: Is sorted using SIMD instructions

On Thursday, 12 April 2018 at 07:25:27 UTC, Per Nordlöw wrote: Neither GCC, LLVM nor ICC can auto-vectorize (and use SIMD) the seemly simple function bool is_sorted(const int32_t* input, size_t n) { if (n < 2) { return true; } for (size_t i=0; i < n - 1; i++) { if (

Re: newCTFE Status April 2018

On Sunday, 8 April 2018 at 09:44:04 UTC, Stefan Koch wrote: [ ... ] And again I find a case which we did not handle for years. When we directly interpret a function which takes a reference to a static immutable global as parameter. This global will be full of zeros since newCTFE had no funct

Re: What are AST Macros?

On Friday, 13 April 2018 at 00:37:39 UTC, jmh530 wrote: Could AST macros replace things like @safe/@nogc and enable the user to create their own (like a @supersafe that disallows @trusted)? Short Answer: Yes. If the AST-Macro facilities are built with that use in mind.

Re: CTFE in .di files

On Tuesday, 17 April 2018 at 22:19:19 UTC, Manu wrote: I've been having some problems like this: https://issues.dlang.org/show_bug.cgi?id=18774 I have .di files with mixins that generate declarations using CTFE. Trouble is, executing the CTFE seems to leave residual references to symbols whic

Re: Places to hang out in Munich the day before the conference

On Wednesday, 25 April 2018 at 06:59:37 UTC, Shachar Shemesh wrote: Hello everybody, I'll be arriving in Munich on the morning of May 1st. I was wondering whether anyone has any recommendations as to how to spend that day? Thanks, Shachar NH Hotel :)

Re: Static Analysis / Code Scanning Tool (SAST) for D?

On Saturday, 28 April 2018 at 15:30:01 UTC, Jonathan M. Wilbur wrote: Does anybody know of a SAST tool that can scan D code for security vulnerabilities? In other words, does anybody know of something that will analyze raw D source code for security vulnerabilities that the human eye may have m

Re: Lightening cable?

On Monday, 30 April 2018 at 19:30:25 UTC, Luís Marques wrote: Hi. Can anyone staying at the conference hotel lend me an iPhone charging cable? Even just for a few minutes would help. I forgot mine :( It's a normal USB-A-mini right?

Re: Why is 64-bit dmd not built as part of the Windows release?

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote: I don't know why even bother with 32-bit dmd to begin with, but at least there should be an option. [...] You need to do make clean. As the backend build with debug symbols will be ABI incompatible to the release frontend.

Re: Default Template Instantiation

On Thursday, 17 May 2018 at 08:37:01 UTC, Heromyth wrote: On Monday, 19 September 2016 at 22:59:53 UTC, Jonathan Marler wrote: On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote: [...] Good example, thanks for the information. Maybe the compiler can do more works to make the c

Re: Support alias this in module scope?

On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: Okay, I'm still really angry about the stupid stupid decision to make C++ namespaces into scopes rather than just a detail used for mangling, with absolutely no consultation of the community, in particular the target audience, who are unan

Re: extend foreach to work on non-arrays

On Thursday, 24 May 2018 at 22:43:00 UTC, IntegratedDimensions wrote: Doesn't make any sense? foreach(a; x) if x is not an array then a = x and the loop reduces simply and function to the case it is not so their can be no harm. It unifies the concepts so that one does not have to worry if x

Re: Remember the Vasa! by Bjarne Stroustrup

On Tuesday, 29 May 2018 at 05:47:32 UTC, Let-It-Go wrote: On Tuesday, 29 May 2018 at 05:11:27 UTC, Dmitry Olshansky wrote: D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe. There is the core of the problem. Because you

Re: std.digest can't CTFE?

On Thursday, 31 May 2018 at 21:29:13 UTC, Manu wrote: "CTFE Digests do not work in CTFE" That's an unfortunate limitation... why is, those things? :( Because CTFE cannot do things which are technically ABI dependent. You can work around it with code like this: T fromBytes(T, Endianess endian

Re: std.digest can't CTFE?

On Friday, 1 June 2018 at 18:30:34 UTC, Sisor wrote: On Friday, 1 June 2018 at 14:56:32 UTC, Stefan Koch wrote: On Thursday, 31 May 2018 at 21:29:13 UTC, Manu wrote: "CTFE Digests do not work in CTFE" That's an unfortunate limitation... why is, those things? :( Because CTFE cannot do things

Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case

On Tuesday, 5 June 2018 at 11:35:10 UTC, Ethan wrote: On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: And, honestly, with this method, I am already seeing the workaround. Because I've had to do it a ton of times already with other templates. Run a search for 'mixin( "import' in Binderoo

Re: pure functions cannot be removed, actually: pure vs. total

On Tuesday, 5 June 2018 at 14:48:23 UTC, FeepingCreature wrote: I'm just posting to clear up the misunderstanding that a call to a pure function can be removed. Actually, even calls to strongly pure functions cannot always be removed. This is because there is one thing that a pure function can

Re: pure functions cannot be removed, actually: pure vs. total

On Thursday, 7 June 2018 at 22:23:09 UTC, Steven Schveighoffer wrote: {...} That a function could return does not mean it will. int fn (int arg) /*strongly*/ pure { if (arg == 42) return 42; else (arg < 43) return fn(--arg); else return fn(++arg); } do you see the problem? I

Re: Identifier hierarchy

On Monday, 11 June 2018 at 13:47:41 UTC, Luís Marques wrote: On Monday, 11 June 2018 at 13:39:22 UTC, Basile B. wrote: the FQN is working here but i find the first message a bit confuse. Not sure if this small runnable represents the issue ? --- module runnable; import std.stdio, std.traits;

newCTFE: perliminary delegate support is in!

Good day ladies and gentleman, it is my distinct please to announce that a new feature just landed in newCTFE. !!! DELEGATES !!! this means the following code will now work: int square_of_x_plus_x(int x) pure { int passThrough(int y) pure { assert(x == y); int y2 = x;

Re: newCTFE: perliminary delegate support is in!

On Wednesday, 13 June 2018 at 06:10:26 UTC, Cym13 wrote: That's very nice! Out of curiosity, what was the reason to avoid a conventional stack? Or was it a consequence more than a design decision? (If you've explained it before, feel free to just throw the old post at me) It was an initial

Re: D code obfuscator

On Thursday, 14 June 2018 at 05:21:03 UTC, DigitalDesigns wrote: Just one question! Are you kidding me? He most certainly is not. Infact I prefer size-optimized machinecode over source sometimes. Because it is a trustworthy representation of what the program does. Rather then being a half-t

Re: Ideas for students' summer projects

On Wednesday, 23 May 2018 at 02:38:17 UTC, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Fork newCTFE and bring it to completion: https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/ Mike I am still working on newCTFE,

Re: Phobos' std.conv.to-conversion from enum to string doesn't scale beyond hundreds of enumerators

On Friday, 22 June 2018 at 00:50:05 UTC, Steven Schveighoffer wrote: On 6/21/18 6:46 PM, Per Nordlöw wrote: I've discovered the annoying fact that std.conv.to doesn't scale for enum to string conversion when the enum has hundreds of members. This because of a call to `NoDuplicates` which has (

Re: Phobos' std.conv.to-conversion from enum to string doesn't scale beyond hundreds of enumerators

On Friday, 22 June 2018 at 20:23:51 UTC, Steven Schveighoffer wrote: On 6/22/18 2:15 PM, Steven Schveighoffer wrote: On 6/22/18 1:41 PM, Stefan Koch wrote: (I'd suggest a non-recursive mergesort.) How will that perform in CTFE? I'm concerned about swapping values making it allocate new array

Re: Writing a compiler in CTFE

On Sunday, 1 July 2018 at 13:51:36 UTC, MysteryMan wrote: [...] For speed of development, instead of having to compile a compiler that then compiles the program I figured using D's CTFE and import could work. For a monolithic compiler file import is used. This is all easily within D's grasp.

newCTFE report July

Hi Guys, last month I did the work make this snippet compile and execute correctly: static immutable four = [1, 2, 3, 4]; int fn(int idx = 2) { int fn2(const int* x) { return x[idx]; } return fn2(&four[0]) + *(&four[0]); } static assert(fn() == 4); There where two major

Re: newCTFE report July

On Wednesday, 18 July 2018 at 18:36:37 UTC, H. S. Teoh wrote: On Wed, Jul 18, 2018 at 06:28:30PM +, Stefan Koch via Digitalmars-d wrote: [...] Good to hear that progress on newCTFE is still being made. What's your current estimate on when it will be production-ready? T I am goi

Re: Bizarre Memory leak issue ??? help!

On Friday, 27 July 2018 at 04:56:01 UTC, Mark wrote: Hello, I am building a toy compiler in D, and during this I ran into a situation. It involves checking the header of each function, going through the arguments, and seeing if there is any duplicate identifiers. I have a python script that

Re: Moving druntime into the DMD repository

On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: This a thread to explore whether it would be feasible to do so. What do you think? -- One is a compiler the other is a (optional!) library. merging the two means forcing druntime onto people who want to use dmd. the sepera

Re: skinny delegates

On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the entire data structure of the item in question is an rvalue, and would fit into the data pointer part of the delega

Re: skinny delegates

On Thursday, 2 August 2018 at 12:57:02 UTC, Steven Schveighoffer wrote: On 8/2/18 8:42 AM, Stefan Koch wrote: On Monday, 30 July 2018 at 21:02:56 UTC, Steven Schveighoffer wrote: Would it be a valid optimization to have D remove the requirement for allocation when it can determine that the ent

Re: DIP 1017--Add Bottom Type--Community Review Round 1

On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [ ... ] Regarding the rationale: It should be pointed out that this is a further complication of the type-system (which is alre

Re: DIP 1017--Add Bottom Type--Community Review Round 1

On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote: On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": I hope there is a better name than Tbottom. A name like that is not

Re: DIP 1017--Add Bottom Type--Community Review Round 1

On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote: On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote: meant is(typeof(*null) == typeof(assert(0))) How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error

Re: DIP 1017--Add Bottom Type--Community Review Round 1

On Saturday, 11 August 2018 at 00:01:34 UTC, Timon Gehr wrote: On 11.08.2018 01:40, Stefan Koch wrote: Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer. No tha

Re: A site like cppinsights.io, but for D?

On Sunday, 26 August 2018 at 17:39:22 UTC, Alexander Nicholi wrote: I just ran across this website that does some pretty interesting deconstructions of C++ code, and I was wondering if anything like this exists for D. Apparently the main purpose is source-to-source tra

Re: Looking for a mentor for SAoC

On Monday, 27 August 2018 at 21:32:10 UTC, David Nadlinger wrote: On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote: generating it is not the problem but linking it on windows currently requires the MS linker. Is that true, though? DMD ships with LLD these days. — David Really ...

Re: dmd as a library for scripting/JIT?

On Friday, 14 September 2018 at 16:02:36 UTC, dennis luehring wrote: i've got user defined flow charts in my C++ application that calling C/C++ Code - could be possible to embedd dmd as a library, generate D code out of my flow charts and execute the "compiled" code directly without doing file

Re: Funny way to crash dmd and brick the whole computer

On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote: CTE fib : module fib_cte; import std.stdio; long fib(long n) { if (n <= 1) return 1; return fib(n - 1) + fib(n - 2); } static immutable valueFib = fib(46); void main() { writeln(valueFib); } to be fair, that function is inc

Re: Yet another binding generator (WIP)

On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] How does it compare to dstep?

Re: Thread-safe attribution

On Sunday, 7 October 2018 at 02:59:12 UTC, Manu wrote: On Sat, Oct 6, 2018 at 7:40 PM Nicholas Wilson via Digitalmars-d wrote: [...] One thing that occurred to me is that _objects_ are shared, whereas _functions/methods_ (and their parameters) are thread safe . Theadsafe is kind of like a

Re: [OT] Generative C++

On Thursday, 3 August 2017 at 23:59:01 UTC, jmh530 wrote: On Thursday, 3 August 2017 at 22:38:08 UTC, Joakim wrote: 30-page long thread from four years ago, enjoy: :D http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com This post from Walter may summarize his feelings: http://forum

Re: [OT] Generative C++

On Friday, 4 August 2017 at 12:34:21 UTC, 12345swordy wrote: [ ... ] I can understand that you don't want to be trolled. Many other people feel the same way. Therefore I'd ask you to reflect on what it means to be trolling.

Re: [OT] Generative C++

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote: On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote: On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote: "Enable writing compiler-enforced patterns for any purpose: coding standards (e.g., many Core Guidelines “enforce”

Re: [OT] Generative C++

On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote: On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote: On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote: On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote: On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy

Re: [OT] Generative C++

On Friday, 4 August 2017 at 16:54:44 UTC, 12345swordy wrote: On Friday, 4 August 2017 at 16:36:22 UTC, Stefan Koch wrote: On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote: On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote: On Friday, 4 August 2017 at 16:11:11 UTC, 12345swo

Re: delegate confusion

On Friday, 4 August 2017 at 17:27:52 UTC, Timon Gehr wrote: In D, the foreach loop variable is a distinct declaration for each loop iteration, while in C#, the same loop variable is repeatedly reassigned. In C#, the issue is bad language design, while in D, the issue is a buggy compiler impleme

  1   2   3   4   5   6   7   8   9   10   >