Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote: On 2/10/16 11:51 PM, Matt Elkins wrote: * The in keyword. This is nice syntactic sugar over having a special trait in C++ which deduces whether to pass by value or const-reference. "foo(in bar)" is way more readable

Re: Things that keep D from evolving?

On 2/12/16 9:37 AM, Matt Elkins wrote: On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote: On 2/10/16 11:51 PM, Matt Elkins wrote: * The in keyword. This is nice syntactic sugar over having a special trait in C++ which deduces whether to pass by value or const-reference.

Re: Things that keep D from evolving?

On 2/10/16 11:51 PM, Matt Elkins wrote: * The in keyword. This is nice syntactic sugar over having a special trait in C++ which deduces whether to pass by value or const-reference. "foo(in bar)" is way more readable than something like "foo(traits::fast_param bar)" Hm... in is short for scope

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote: On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: On 2/12/16 9:37 AM, Matt Elkins wrote: [...] Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote: note that 'in' and 'scope'(other than for delegates) parameter storage class usage should be avoided. It really should be a warning. Add to docs!

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: It could potentially differ based on the type being passed, Yes, that's what I meant. but I'm unaware of such an optimization, Hm. Unfortunate. and it definitely isn't triggered specifically by 'in'. 'in' is

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: On 2/12/16 9:37 AM, Matt Elkins wrote: [...] Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class. -Steve I'd imagine GCC or LLVM may be able to

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote: On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote: On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: On 2/12/16 9:37 AM, Matt Elkins wrote: [...] Pass by reference and pass by value means different

Re: Things that keep D from evolving?

On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote: - Syntactic sugars (associtive arrays, powerful foreach, slices...) I'm still adjusting to the idea of AAs as part of the language rather than library. Not sure I like it, but on the other hand it doesn't really hurt. The

Re: Things that keep D from evolving?

On Wednesday, 10 February 2016 at 20:21:22 UTC, Chris Wright wrote: On Wed, 10 Feb 2016 08:57:51 +, thedeemon wrote: Currently (at least last time I checked) GC pauses the world, then does all the marking in one thread, then all the sweeping. Right. We can do the marking in several

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote: There are several reasons I want to use D rather than C# / Go / something else: I will focus on comparing against C++, because that has been my favorite general purpose language for a long time. While I often have to use C, Java, C#,

Re: Things that keep D from evolving?

On Thursday, 11 February 2016 at 05:05:22 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote: - Syntactic sugars (associtive arrays, powerful foreach, slices...) I'm still adjusting to the idea of AAs as part of the language rather than library. Not sure I

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote: I would want it to be solved rather than being worked on... which requires design change which is probably not going to happen. There is still room for improvement though. Right. I think there are at least two things that can improve

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote: On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote: The GC itself may still be far from perfect but its much better than it was, and there are more options now. I have found emsi containers (built on top of Andrei's

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote: There are several reasons I want to use D rather than C# / Go / something else: - Interfacing with native API without jumping through hoops Well, but the hoops are there to get safe and fast GC. - Incredibly high abstraction and

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote: Well, GC being better than it used to be doesn't change the fact it's still the > worst of it's kind. I don't know if this[1] work actually got released or merged but looks like it's abandoned. Pretty sad as it seemed very promising. [1]

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad wrote: C++ compilers have lots of optional warnings/errors, so it is quite possible. But I suppose those that want it would rather use Go, C# or some other GC language than can do ahead of time compilation. There are several

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote: The GC itself may still be far from perfect but its much better than it was, and there are more options now. I have found emsi containers (built on top of Andrei's allocator) pretty nice myself for my own use. Well, GC being

Re: Things that keep D from evolving?

On Tue, 09 Feb 2016 14:35:48 +, Ola Fosheim Grøstad wrote: > On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote: >> There are several reasons I want to use D rather than C# / Go / >> something else: >> - Interfacing with native API without jumping through hoops > > Well, but the hoops are

Re: Things that keep D from evolving?

On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim Grøstad wrote: Not incredibly high level abstraction... But I get what you mean. It is fairly high level for a low level language. Coming from C#, it looks amazing but probably not that incredible when coming from C++. So you want

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote: On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? Unions and easy type casting prevent precise GC. Lack of write barriers for reference-type fields prevent

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html Well, the latest Intel CPUs have a theoretical throughput of 30GB/s... so that makes for up to 30MB/ms. But language changes are needed, I think. I also

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? Unions and easy type casting prevent precise GC. Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed

Re: Things that keep D from evolving?

On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote: > On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: >> What language semantics prevent precise & fast GC implementations? > > easy type casting prevent precise GC. To expand on this point: A GC makes a tradeoff between allocating

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to

Re: Things that keep D from evolving?

On Sunday, 7 February 2016 at 02:46:39 UTC, Marco Leise wrote: My code would not see much ref counting in performance critical loops. There is no point in ref counting every single point in a complex 3D scene. I could imagine it used on bigger items. Textures for example since they may be used

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote: This prevents fast GC: Pointers. Would it be possible to write a fast garbage collector that just didn't track any pointers? Just offer a head's up that if you use "this collector" and pointers on collectable data,

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? This prevents fast GC: Pointers. This prevents precise GC: internal Pointers + FFI. Go now has <10ms latency for small heaps, <20ms latency for up to 100GB heaps and

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 15:14:06 UTC, Kagamin wrote: On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise Lack of resources. Precise GC needs to know which fields are pointers. Somebody must generate that map. AFAIK there was an experiment

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote: On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote: Can't be done with the root class because classes never trigger RAII outside of (deprecated) scope

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote: Can't be done with the root class because classes never trigger RAII outside of (deprecated) scope allocations. Not sure what you mean. The class instance

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote: Can't be done with the root class because classes never trigger RAII outside of (deprecated) scope allocations. Not sure what you mean. The class instance doesn't have to trigger anything? You "retain(instance)" to increase the

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: Nothing prevents you from creating your own reference counting mechanism. A struct wrapper doesn't give the things you need to reliably handle inheritance. interface A {} interface B {} class C : A, B {} void

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote: Might as well manually free and delete instead. Not really, this was used in Objective-C before ARC. But you can always move retain/release/borrow/unborrow into your own pointer struct like shared_ptr.

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:36:28 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote: On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: Nothing prevents you from creating your own reference counting mechanism. A

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote: On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: Nothing prevents you from creating your own reference counting mechanism. A struct wrapper doesn't give the things you need to reliably handle

Re: Things that keep D from evolving?

Am Sat, 06 Feb 2016 11:47:02 + schrieb Ola Fosheim Grøstad : > Of course, Swift does not aim for very high performance, but for > convenient application/gui development. And frankly JavaScript is > fast enough for that kind of programming. My code would

Re: Things that keep D from evolving?

Am Sat, 06 Feb 2016 23:18:59 + schrieb Ola Fosheim Grøstad : > Things that could speed up collection: > - drop destructors so you don't track dead objects Interesting, that would also finally force external resources off the GC heap and into deterministic

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote: What makes it impossible to have ref counted classes? Nothing. Then why do we need DIP74 ? And why documentation says RefCounted doesn't work with classes?

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 11:33:05 UTC, rsw0x wrote: On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: reference counting is incredibly slow, DIP74 attempts to partially amend that in D as it can't be done any other way besides compiler help. IIRC, it essentially

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise Lack of resources. Precise GC needs to know which fields are pointers. Somebody must generate that map. AFAIK there was an experiment on that. fast GC Fast GC needs to be notified about

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote: On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote: What makes it impossible to have ref counted classes? Nothing. Then why do we need DIP74 ? I think they aim for compiler optimizations, like ARC on Swift. But

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote: On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote: What makes it impossible to have ref counted classes? Nothing. Then why do we need DIP74