Re: D 2015/2016 Vision?

On Sunday, 18 October 2015 at 04:03:49 UTC, Andrei Alexandrescu wrote: On 10/18/15 1:57 AM, bitwise wrote: On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote: On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On

Re: D 2015/2016 Vision?

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote: On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that

Re: D 2015/2016 Vision?

On 10/18/15 1:57 AM, bitwise wrote: On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote: On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded

Re: D 2015/2016 Vision?

On Wednesday, 14 October 2015 at 16:24:25 UTC, Ola Fosheim Grøstad wrote: Yeah, well, not even sure what C++ idioms are? The ones that a sold on slides at CppCon, or the ones we find at Github? :-) Off the top of my head: 1) polymorphic value types 2) references in fields 3) value type strings

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 09:01:54 UTC, Ola Fosheim Grøstad wrote: You don't have to, you can use a region allocator. I wrote one and use it in my code for everything. I guess the conclusion is that C++ programmers used to C++ way of resource management and don't want to change their

Re: D 2015/2016 Vision?

On Wednesday, 14 October 2015 at 16:12:59 UTC, Kagamin wrote: On Monday, 12 October 2015 at 09:01:54 UTC, Ola Fosheim Grøstad wrote: You don't have to, you can use a region allocator. I wrote one and use it in my code for everything. I guess the conclusion is that C++ programmers used to C++

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: For the THIRD time, I'll post my example: class Texture { } class Texture2D : Texture { this() { /* load texture... */ } ~this { /* free texture */ } // OOPS, when, if ever, will this be called? } Now, does this really

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote: Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types. If it doesn't make sense for reference types to be value types, then your suggestion to use structs (value

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 07:39:30 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote: Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types. If it doesn't make sense for reference types to be

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 07:39:30 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote: Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types. If it doesn't make sense for reference types to be

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 08:49:24 UTC, Jonathan M Davis wrote: On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: I've programmed extensively in C++ with smart pointers, and in my experience, circular references

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 08:59:55 UTC, deadalnix wrote: Well technically, there is still ownership: the GC owns everything. But yeah, you don't need to care about for this very reason. Only if you have finalizers. Without finalization it is better to think of the GC as a memory

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 08:00:59 UTC, Jonathan M Davis wrote: You can stick value types on the heap and pass around pointers or references to them, but then you're not dealing with polymorphism. As soon as you choose to use value types you already get the first problem: pointers or

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: I've programmed extensively in C++ with smart pointers, and in my experience, circular references are rarely a problem. There are some cases where it's obvious that you have one (e.g. where one object owns another and they

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: I've programmed extensively in C++ with smart pointers, and in my experience, circular references are rarely a problem. There are some cases where it's obvious that

Re: D 2015/2016 Vision?

On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote: That's all understandable. What's not understandable is when one insists that a necessity to figure out ownership for every non-resource object in C++ is superior to D. You don't have to, you can use a region allocator.

Re: D 2015/2016 Vision?

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote: On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that

Re: D 2015/2016 Vision?

On 10/8/2015 11:56 AM, Ola Fosheim Grøstad wrote: On Thursday, 8 October 2015 at 18:19:51 UTC, Jim Hewes wrote: Yes, there are libraries, but for it to be pleasant I think language support is needed. I've linked to this video before, but it is quite entertaining if you haven't seen it yet:

Re: D 2015/2016 Vision?

On Friday, 9 October 2015 at 20:16:42 UTC, Jim Hewes wrote: Yeah, I watched that after I saw your other post with the link. Thanks. One early question that I have (that someone else also asked in a comment below the video) is about design and the granularity of actors. What sorts of things do

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:31:58 UTC, Jonathan M Davis wrote: I don't think the problem is with structs. The problem is that programmers coming from other languages default to using classes. The default in D should always be a struct. You use a class because you actually need inheritance

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:05:53 UTC, Kagamin wrote: On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote: If it takes long enough that C++ has reflection, modules, ranges, stackless coroutines, concepts, etc, then I gotta be honest, I'm gonna start worrying about investing too

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:15:12 UTC, Ola Fosheim Grøstad wrote: You have to use weak pointers for back references. http://en.cppreference.com/w/cpp/memory/weak_ptr I suspected as much and the next question is how is it better than C# solution except that one used to cope with C++

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote: If it takes long enough that C++ has reflection, modules, ranges, stackless coroutines, concepts, etc, then I gotta be honest, I'm gonna start worrying about investing too much time in D. You manage resources with reference

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 11:31:49 UTC, Kagamin wrote: cyclic graph. If you must manually verify the graph and put weak references appropriately - what kind of design in that? It's a system programming language design... If you plan your model before coding it is rather easy to detect

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:26:22 UTC, Kagamin wrote: On Thursday, 8 October 2015 at 10:15:12 UTC, Ola Fosheim Grøstad wrote: You have to use weak pointers for back references. http://en.cppreference.com/w/cpp/memory/weak_ptr I suspected as much and the next question is how is it

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote: On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim Grøstad wrote: Are you thinking about Rust, or some other language? All of the ones that explore this area. Rust, ATS, Idris, F* Oh, yeah, sure. I wondered more if

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:34:44 UTC, Ola Fosheim Grøstad wrote: I don't know. I don't like extensive reference counting and don't use weak_ptr. One can usually avoid cycles for resources by design. The required design is that a resource handle must reside in a non-resource object,

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 11:15:35 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote: On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim Grøstad wrote: Are you thinking about Rust, or some other language? All of the ones that explore

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 08:21:09 UTC, Kagamin wrote: On Tuesday, 6 October 2015 at 20:31:58 UTC, Jonathan M Davis wrote: I don't think the problem is with structs. The problem is that programmers coming from other languages default to using classes. The default in D should always be a

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 12:10:24 UTC, Ola Fosheim Grøstad wrote: On Thursday, 8 October 2015 at 11:31:49 UTC, Kagamin wrote: cyclic graph. If you must manually verify the graph and put weak references appropriately - what kind of design in that? It's a system programming language

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 13:20:51 UTC, Paulo Pinto wrote: It is really hard to keep up with JVM, .NET and occasional look into C++. The languages are easy when compared to the whole ecosystem, hence why I went silent. I've found getting a good understanding of C++11/14 to be a serious

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: One advantage of using smart pointers with a GC is that the GC can then clean up circular references, and you don't necessarily even need weak pointers (though there are bound to be cases where they'd still be desirable). But

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 15:30:17 UTC, Jonathan M Davis wrote: On Wednesday, 7 October 2015 at 12:59:05 UTC, bitwise wrote: On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote: RefCounted isn't implemented for classes, but there's no reason why it shouldn't work. Really,

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 16:38:31 UTC, Meta wrote: Why, because you can take their address? You or someone you call can take the address. If there is a way to distinguish instances one way or another then it isn't a value, it is an object. Doesn't mean your code is taking the address.

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 10:05:53 UTC, Kagamin wrote: On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote: If it takes long enough that C++ has reflection, modules, ranges, stackless coroutines, concepts, etc, then I gotta be honest, I'm gonna start worrying about investing too

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis wrote: Maybe, but having classes be value generally makes no sense, because you can't use polymorphism with value types. This is a huge generalization, and is incorrect. You can still use inheritance. Classes are inherently

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 16:14:05 UTC, Jonathan M Davis wrote: On Thursday, 8 October 2015 at 15:59:23 UTC, bitwise wrote: Again, it's much easier to be careful about this when the author's intent is baked into the class. That may be, but my point was that it doesn't actually guarantee

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 16:17:49 UTC, bitwise wrote: Classes are inherently reference types given their semantics. Incorrect. Inaccurate maybe, but something that has an identity is not a value type. Value types are by definition identity-less. The type system of C/C++/D doesn't

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 16:29:58 UTC, Ola Fosheim Grøstad wrote: Inaccurate maybe, but something that has an identity is not a value type. Value types are by definition identity-less. The type system of C/C++/D doesn't really provide guarantees needed to have proper value types. Why,

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 15:51:44 UTC, Ola Fosheim Grøstad wrote: So I don't think there are _good_ reasons to call finalizers/destructors on the GC heap, it's a sign of a bad model where the responsibilities are unclear. GC objects should only "own" memory on the GC heap. As far as I

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 15:59:23 UTC, bitwise wrote: Again, it's much easier to be careful about this when the author's intent is baked into the class. That may be, but my point was that it doesn't actually guarantee that the object is going to be destroyed determinstically. That's

Re: D 2015/2016 Vision?

On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that should be the case. -- Andrei

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 18:19:51 UTC, Jim Hewes wrote: I've recently become curious about the actor model and would like to learn more about it and maybe play around with it a bit. The C++ Actor Framework looks good, but unfortunately it doesn't yet work with MSVC so I'm waiting for

Re: D 2015/2016 Vision?

Am Tue, 6 Oct 2015 18:27:28 -0700 schrieb Walter Bright : > On 10/4/2015 11:02 AM, bitwise wrote: > > For example, streams. > > No streams. InputRanges. ... what bitwise said ... We had this discussion at least once and it did not change my mind back then: Ranges and

Re: D 2015/2016 Vision?

On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that should be the case. -- Andrei Can you comment on the status of the next vision document? Thanks =)

Re: D 2015/2016 Vision?

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote: On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that

Re: D 2015/2016 Vision?

On 10/9/15 4:47 AM, bitwise wrote: On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote: On 10/8/15 5:59 PM, bitwise wrote: With DIP74, the ref counting is hard coded into the type itself. I think that should be the case. -- Andrei Can you comment on the status of the

Re: D 2015/2016 Vision?

On 10/8/2015 4:15 AM, Ola Fosheim Grøstad wrote: I personally think that they future is with actor-based programming in combination with substructural/behavioural typing since it lends itself to distributed computing, multi core etc. I've recently become curious about the actor model and would

Re: D 2015/2016 Vision?

On 10/8/2015 8:51 AM, Ola Fosheim Grøstad wrote: On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote: Yes, in general ownership should not be circular at all. It should be a DAG growing from the current actor/process/stack in an unbroken chain of ownership-references. +1.

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: I'm not sure what else I can say. The

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: That no, but this yes (at least in C#): using (LevelManager mgr = new LevelManager()) { // // Somewhere in the call stack Texture text = mgr.getTexture(); } --> All level resources gone that require manual

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 07:35:05 UTC, ponce wrote: On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: That no, but this yes (at least in C#): using (LevelManager mgr = new LevelManager()) { // // Somewhere in the call stack Texture text =

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 02:41:12 UTC, Walter Bright wrote: On 10/6/2015 7:04 PM, bitwise wrote: On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright wrote: On 10/4/2015 11:02 AM, bitwise wrote: For example, streams. No streams. InputRanges. This is too vague to really

Re: D 2015/2016 Vision?

On 06-Oct-2015 23:44, ponce wrote: On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: Unfortunately, it is quite common to need both virtual functions and deterministic destruction. It isn't helpful to disregard the problem by saying "you should have used a struct", in many

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 07:35:05 UTC, ponce wrote: On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: That no, but this yes (at least in C#): using (LevelManager mgr = new LevelManager()) { // // Somewhere in the call stack Texture text =

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote: On Wednesday, 7 October 2015 at 12:56:32 UTC, bitwise wrote: On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: [...] That no, but this yes (at least in

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis wrote: On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote: Well, again that has it's pros and cons. This is why I just want a normal language solution like DIP74.

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote: On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis wrote: On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote: Well, again that has it's pros and cons.

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 10:44:50 UTC, Jonathan M Davis wrote: Having ref-counting built into the language will allow us to make it more efficient and provide some safety guarantees that can't necessarily be provided in a struct, but it doesn't make it so that no one can misuse

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 10:50:35 UTC, Namespace wrote: Language-supported ref-counting wouldn't fix that. As long as you're allowed to put a ref-counted object inside of a GC-managed object, it's possible that the GC will ultimately managed the lifetime of your ref-counted object - or

Re: D 2015/2016 Vision?

Well, except that then it's less obvious that an object is ref-counted and less likely that the programmer using it will realize that the object expects to have a deterministic lifetime. So, it might actually make the situation worse and make it so that programmers are more likely to get

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote: On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote: Really, I don't get why everyone wants to have builtin refcounting, when all that's required is a working way to make escape-proof references. Because there is no

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote: Because there is no guarantee that others, who use your code, get it right and use those constructs. The obvious way would be to make the constructor private and only provide a factory method returning a Scoped!Texture2D. I just

Re: D 2015/2016 Vision?

Language-supported ref-counting wouldn't fix that. As long as you're allowed to put a ref-counted object inside of a GC-managed object, it's possible that the GC will ultimately managed the lifetime of your ref-counted object - or even that it will never be destroyed, because it simply isn't

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 11:27:49 UTC, Marc Schütz wrote: On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote: Because there is no guarantee that others, who use your code, get it right and use those constructs. The obvious way would be to make the constructor private and

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 05:13:06 UTC, Walter Bright wrote: On 10/6/2015 7:57 PM, bitwise wrote: Again though, if I have to restate what I've been arguing for as simply as possible, it's that I want to use RAII and polymorphism at the same time, as a natural language solution. DIP74

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 12:56:32 UTC, bitwise wrote: On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: [...] That no, but this yes (at least in C#): using (LevelManager mgr = new LevelManager()) { //

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote: RefCounted isn't implemented for classes, but there's no reason why it shouldn't work. Really, I don't get why everyone wants to have builtin refcounting, when all that's required is a working way to make escape-proof

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote: On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 17:20:39 UTC,

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 11:21:04 UTC, Namespace wrote: Well, except that then it's less obvious that an object is ref-counted and less likely that the programmer using it will realize that the object expects to have a deterministic lifetime. So, it might actually make the situation

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote: On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote: In general, I advocate any form of automatic memory/resource management. With substructural

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 17:22:49 UTC, Atila Neves wrote: On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote: On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote: In general, I advocate any

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 12:59:05 UTC, bitwise wrote: On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote: RefCounted isn't implemented for classes, but there's no reason why it shouldn't work. Really, I don't get why everyone wants to have builtin refcounting, when all

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote: In general, I advocate any form of automatic memory/resource management. With substructural type systems now being my favorite, but they still have an uphill battle for adoption. Are you thinking about Rust, or some other

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 15:13:40 UTC, Jonathan M Davis wrote: std.typecons.RefCounted aside, it's quite possible as-is to implement smart pointers in D with structs, thus providing deterministic destruction for reference types. I don't know why RefCounted wasn't implemented to work

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 15:13:40 UTC, Jonathan M Davis wrote: the GC heap, which is unnecessarily limiting, particularly since in many cases, it's perfectly okay to let objects that might normally be destroy deterministically to be destroyed at the GC's leisure. This is a costly (in

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote: In general, I advocate any form of automatic memory/resource management. With substructural type systems now being my favorite, but they still have an

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 00:17:37 UTC, bitwise wrote: -again, alias this allows class references to escape their RAII containers and can cause access violations as show here: http://forum.dlang.org/post/zfggjsjmfttbcekqw...@forum.dlang.org This isn't really a problem as it can be

Re: D 2015/2016 Vision?

On 10/6/2015 7:57 PM, bitwise wrote: What can a stream do that a range cannot? I was trying to make my case for polymorphism, so I haven't thought much about streams specifically, but one obvious thing that stands out is growing on demand. Stream s = new Stream(4); s.write(1); s.write(2); //

Re: D 2015/2016 Vision?

You don't need RC, just use Unique. In most cases you don't want to use RC, because you never have control over the ownership.

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: I'm not sure what else I can say. The example I posted says it all, and it can't be done properly in D (or C#, but why lower the bar because of their mistakes? ;)

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 19:15:09 UTC, Paulo Pinto wrote: GC is not an hindrance when the languages are built to properly work with it. -- Paulo +1, tired of repeating this.

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote: [...] It's a side effect of having the lifetime of an object managed by the GC. There's no way around that except to use something else like manual memory

Re: D 2015/2016 Vision?

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote: Well, again that has it's pros and cons. This is why I just want a normal language solution like DIP74. They're not the same thing at all. scoped is supposed to put the class on the stack, not the heap. And it's not ref-counted. It's

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:04:06 UTC, jmh530 wrote: On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: In most cases though, just don't use classes. In most cases, inheritance is a horrible way to write programs anyway, because it's _horrible_ for code reuse. It

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: But in general, at this point, with D, if you want deterministic destruction, then you use structs. Classes are not the appropriate place for it. If they were ref-counted, then they could be, but as long as they're not, then

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: I'm not sure what else I can say. The example I posted says it all, and it can't be done properly

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: So, you're saying you want me to just revert back to manual resource management and accept that huge resources like textures and such may just leak if someone doesn't use them right? or throws an exception? in a language like D that

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: In most cases though, just don't use classes. In most cases, inheritance is a horrible way to write programs anyway, because it's _horrible_ for code reuse. It definitely has its uses, but I've found that I rarely need classes

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: I want polymorphism AND deterministic destruction, and the least you could do is just admit that it's a downside to D not having it, instead of trying to tell me that everything I know is wrong.. This problem comes up again and

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:46:00 UTC, ponce wrote: On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: I want polymorphism AND deterministic destruction, and the least you could do is just admit that it's a downside to D not having it, instead of trying to tell me that

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis wrote: For the THIRD time, I'll post my example: class Texture { } class Texture2D : Texture { this() { /* load texture... */ } ~this { /* free texture */ } //

Re: D 2015/2016 Vision?

It's a step simpler with the new inline feature (works sadly only with the -inline flag): pragma(inline, true) auto scoped(T, Args...)(auto ref Args args) if (is(T == class)) { void[__traits(classInstanceSize, T)] buf = void; buf[] = typeid(T).init[]; T obj = cast(T) buf.ptr;

Re: D 2015/2016 Vision?

On Monday, 5 October 2015 at 22:15:59 UTC, bitwise wrote: On Monday, 5 October 2015 at 21:29:20 UTC, Namespace wrote: But you can simply relinquish alias this and use opDispatch. Problem solved. I don't understand what you mean. import std.stdio; struct Scoped(T) { private

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 08:27:02 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis wrote: On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote: Well, again that has it's pros and cons. This is why I just want a normal language solution like

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis wrote: On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote: Well, again that has it's pros and cons. This is why I just want a normal language solution like DIP74. They're not the same thing at all. scoped is supposed to put

Re: D 2015/2016 Vision?

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote: On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis wrote: They're not the same thing at all. scoped is supposed to put the class on the stack, not the heap.

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright wrote: On 10/4/2015 11:02 AM, bitwise wrote: For example, streams. No streams. InputRanges. This is too vague to really respond to. It does serve as an example of the over-emphasis on ranges in the D community. Ranges are great,

Re: D 2015/2016 Vision?

On 10/6/2015 7:04 PM, bitwise wrote: On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright wrote: On 10/4/2015 11:02 AM, bitwise wrote: For example, streams. No streams. InputRanges. This is too vague to really respond to. It does serve as an example of the over-emphasis on ranges in

Re: D 2015/2016 Vision?

On Wednesday, 7 October 2015 at 02:41:12 UTC, Walter Bright wrote: On 10/6/2015 7:04 PM, bitwise wrote: On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright wrote: On 10/4/2015 11:02 AM, bitwise wrote: For example, streams. No streams. InputRanges. This is too vague to really

  1   2   >