Re: Project Highlight: Visual D
On Friday, 12 August 2016 at 17:00:31 UTC, Radu wrote: Mike, Just wanted to say you are doing an awesone work with your blog posts, greatly appreciated! Many thanks for Rainer's hard work also. Visual D is a very important piece of the D language ecosystem and something I use with pleasure on my D projects. Kudos to both of you! Thanks!
Re: DIP1000: Scoped Pointers
On 8/12/2016 1:08 PM, Timon Gehr wrote: On 12.08.2016 21:39, Walter Bright wrote: On 8/12/2016 5:33 AM, Nordlöw wrote: If this is successfully implemented, what will D not be able to do, that Rust can/will? Have ownership semantics for pointers in more complex data structures. In D you'll have to do such with ref counted objects. On the other hand, D code can reference mutable globals in @safe code, whereas Rust cannot. Assuming, of course, I understood the Rust semantics correctly. AFAIU Rust has safe static TLS. Perhaps. Rust changes regularly. Some of the top hits in google are out of date.
Re: DIP1000: Scoped Pointers
On 8/12/2016 5:24 AM, Nordlöw wrote: On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote: The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Thanks for all the work. One remarks. I guess `RefCountedSlice` should infer access permissions of `payload` and `count` to allow RefCountedSlice!(const(T)) right? Is that beyond the scope of the DIP? In order for ref counting to work, and because D doesn't support borrowing, the compiler will have to be aware of ref counting. This DIP is necessary for ref counting to work, but is not sufficient, because it doesn't cover how the compiler semantics will work with ref counting.
Re: DIP1000: Scoped Pointers
On 8/12/2016 5:33 AM, Nordlöw wrote: If this is successfully implemented, what will D not be able to do, that Rust can/will? Have ownership semantics for pointers in more complex data structures. In D you'll have to do such with ref counted objects. On the other hand, D code can reference mutable globals in @safe code, whereas Rust cannot. Assuming, of course, I understood the Rust semantics correctly.
Re: DIP1000: Scoped Pointers
On 11.08.2016 09:48, Walter Bright wrote: On 8/10/2016 11:36 PM, rikki cattermole wrote: Perfect :) The nice thing about this scheme is it can do some things that Rust can't What are some of those things?
Re: This Week in D: debugging uncaught exceptions
On Monday, 8 August 2016 at 04:24:45 UTC, Adam D. Ruppe wrote: I decided to write up a think on untrapping exceptions this week: http://arsdnet.net/this-week-in-d/2016-aug-07.html Next week I'll prolly talk about calling D from Ruby. Last week, we had a status report from Stefan Koch on his CTFE engine. If you aren't already following this, every Sunday night or Monday morning, the little newsletter comes out with a snapshot of forum activity and about half of them have some kind of longer article or tip or other such educational content. The RSS feed (linked on the page) is also a single-page archive so you can search for old things there too! wow this is amazing. I hope they add it as console argument so I can add the argument to my vscode D extension which can call my debugger plugin. It would make the whole experience so much nicer if it could catch all the exceptions.
Re: Project Highlight: Visual D
On Friday, 12 August 2016 at 14:27:48 UTC, Mike Parker wrote: Rainer took some time out of his busy schedule to send me quite a bit of information regarding the development of Visual D. The post is now live at [1]. In the interest of space, I couldn't use it all of his content. If anything feels unclear or disjointed, that's on me and not Rainer. For the record, I'm quite excited about the upcoming VC project integration. As usual, the reddit link is at [2]. [1] https://dlang.org/blog/2016/08/12/project-highlight-visual-d/ [2] https://www.reddit.com/r/programming/comments/4xdr4y/from_the_d_blog_project_highlight_visual_d/ Mike, Just wanted to say you are doing an awesone work with your blog posts, greatly appreciated! Many thanks for Rainer's hard work also. Visual D is a very important piece of the D language ecosystem and something I use with pleasure on my D projects. Kudos to both of you!
Project Highlight: Visual D
Rainer took some time out of his busy schedule to send me quite a bit of information regarding the development of Visual D. The post is now live at [1]. In the interest of space, I couldn't use it all of his content. If anything feels unclear or disjointed, that's on me and not Rainer. For the record, I'm quite excited about the upcoming VC project integration. As usual, the reddit link is at [2]. [1] https://dlang.org/blog/2016/08/12/project-highlight-visual-d/ [2] https://www.reddit.com/r/programming/comments/4xdr4y/from_the_d_blog_project_highlight_visual_d/
Re: DIP1000: Scoped Pointers
On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton Wakeling wrote: I'm not sure I follow. I'm looking for the ability to guarantee that a pointer to a stack-allocated entity will not go out of scope ... more precisely, that the pointer will not become invalid because the data it points to goes out of scope.
Re: DIP1000: Scoped Pointers
On Friday, 12 August 2016 at 12:01:41 UTC, Walter Bright wrote: On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote: On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or 'return scope', where their usage will be limited to the expression they appear in. I want to make sure we have the same understanding here: the use-case I'm interested in is a data structure that needs to hold a reference to data it does not own -- where, obviously, the lifetime of the data structure cannot outlive the lifetime of the data it references. Surely this scope proposal ought to address that use-case? Using ref counted objects should deal with that nicely. I'm not sure I follow. I'm looking for the ability to guarantee that a pointer to a stack-allocated entity will not go out of scope; I'd rather not have to choose between GC allocation or RC allocation (which I presume would both be on the heap...?). Or am I missing some of the potential uses of RC?
Re: DIP1000: Scoped Pointers
On Thursday, 11 August 2016 at 07:48:18 UTC, Walter Bright wrote: On 8/10/2016 11:36 PM, rikki cattermole wrote: Perfect :) The nice thing about this scheme is it can do some things that Rust can't (and Rust can do things that this can't). I suppose it will balance out. If this is successfully implemented, what will D not be able to do, that Rust can/will?
Re: DIP1000: Scoped Pointers
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote: The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Thanks for all the work. One remarks. I guess `RefCountedSlice` should infer access permissions of `payload` and `count` to allow RefCountedSlice!(const(T)) right? Is that beyond the scope of the DIP?
Re: DIP1000: Scoped Pointers
On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote: On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or 'return scope', where their usage will be limited to the expression they appear in. I want to make sure we have the same understanding here: the use-case I'm interested in is a data structure that needs to hold a reference to data it does not own -- where, obviously, the lifetime of the data structure cannot outlive the lifetime of the data it references. Surely this scope proposal ought to address that use-case? Using ref counted objects should deal with that nicely.
Re: DIP1000: Scoped Pointers
On Thursday, 11 August 2016 at 22:03:02 UTC, Walter Bright wrote:
On 8/11/2016 6:38 AM, Sönke Ludwig wrote:
What would be nice to add is a behavior specification for
'scope' member
variables (lifetime considered equal or slightly shorter than
parent object
lifetime). For example the `RefCountedSlice.payload` and
`count` fields could be
annotated with 'scope' to let the compiler actually guarantee
that they won't be
accessible in a way that conflicts with their lifetime (i.e.
the 'scope' return
of 'opIndex' would actually be enforced).
That adds a fair amount of complication I haven't worked
through.
It can probably be done by lowering:
scope T* payload;
Is conceptually:
private T* payload_;
@property scope T* payload() scope {
return payload_;
}
Re: DIP1000: Scoped Pointers
On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote: The scheme does not implement borrowing. References to internal data should be returned via 'return ref' or 'return scope', where their usage will be limited to the expression they appear in. I want to make sure we have the same understanding here: the use-case I'm interested in is a data structure that needs to hold a reference to data it does not own -- where, obviously, the lifetime of the data structure cannot outlive the lifetime of the data it references. Surely this scope proposal ought to address that use-case?
