July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | On 7/8/2014 9:12 PM, Mike wrote: > From what I've observed, I don't think users are complaining that D doesn't do > ref counting. The recurrent observation is "I use C++/Rust/Whatever because they do ref counting, and D uses GC. Therefore I cannot use D." > I believe they are complaining that D doesn't do pervasive > automatic reference counting. ARC has been extensively studied and debated at great length for D. It is not going to work for D. Nobody has figured out a way to make it work for D. Let's move on to what will work. > RefCounted can't be used with D's built-in types, right? The question doesn't make sense. What is a ref counted int? > IMO users are complaining that the current mark-and-sweep GC is not suitable for > certain applications, and they want something that is. The solution that comes > to their mind is pervasive ARC, so that's what they say they want. And because > they can't actually try it for themselves, they aren't convinced it's not a > feasible solution (It would be nice to see some measurable results). We've been over this ground many, many times. Saying people want ARC is correct. Nobody has proposed a feasible design or a way to get to one (I failed at that, too). > If RefCounted is intended to have shared_ptr<T> semantics, then it does appear D > does reference counting, but I believe it's pervasive automatic reference > counting that users really want to try. There's no known way to get ARC in D. |
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/8/2014 3:37 PM, bearophile wrote: > >Walter Bright: > > > >>3. 'ref' means 'borrowed', to use Rust's terminology > >> > >>We're almost there with this. This means better escape analysis, too. > > > >Is "scope" still left for future usage, or used for a different purpose, or deprecated? > > That would have to be addressed as part of this. Does that mean that finally 'scope' will work as advertised? I've been waiting for that for a long time. T -- It's bad luck to be superstitious. -- YHL |
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote: > On 7/8/2014 9:12 PM, Mike wrote: >> From what I've observed, I don't think users are complaining that D doesn't do >> ref counting. > > The recurrent observation is "I use C++/Rust/Whatever because they do ref counting, and D uses GC. Therefore I cannot use D." > > ARC has been extensively studied and debated at great length for D. It is not going to work for D. Nobody has figured out a way to make it work for D. Let's move on to what will work. Agreed. I'm just trying to clarify the problem. I believe ARC and a reference counted library type are quite different solutions to different problems. Adding a ref counted library type, will likely not stop the clamoring. >> RefCounted can't be used with D's built-in types, right? > > The question doesn't make sense. What is a ref counted int? I meant exceptions, dynamic arrays, etc... that are instantiated in the D runtime and expect an automatic memory manager of some type to exist. I don't see how one can use a reference counted library type like RefCounted for these. Feel free to correct me, if I'm wrong. Mike |
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote:
> The question doesn't make sense. What is a ref counted int?
From the typecons documentation:
Example:
// A pair of an $(D int) and a $(D size_t) - the latter being the
// reference count - will be dynamically allocated
auto rc1 = RefCounted!int(5);
:-)
|
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 09/07/14 00:21, bearophile wrote: > 9. Built-in tuples usable in all the most important situations (with a > syntax that doesn't kill possible future improvements of the switch > statement to perform basic pattern matching on structs that have an > optional method named "unapply"). I think it would be possible to implement pattern matching in library code. Something like this: match!(value, (int t) => ifInt(), (char t) => ifChar(), () => noOtherMatch() ); Destructing a type could look something like this: match(value, (type!(Foo), int a, int b) => doSomething(), // match if value is of type Foo and extract it (int a, int b) => doSomething() // match anything that can be destructed to two ints ); The syntax is not so pretty but I think it would be possible. -- /Jacob Carlborg |
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 7/8/2014 10:00 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 7/8/2014 3:37 PM, bearophile wrote:
>>> Walter Bright:
>>>
>>>> 3. 'ref' means 'borrowed', to use Rust's terminology
>>>>
>>>> We're almost there with this. This means better escape analysis,
>>>> too.
>>>
>>> Is "scope" still left for future usage, or used for a different
>>> purpose, or deprecated?
>>
>> That would have to be addressed as part of this.
>
> Does that mean that finally 'scope' will work as advertised? I've been
> waiting for that for a long time.
Help is welcome working on a design.
|
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: > > 5. Precise and Concurrent GC > > There's been a lot of work on this, but I don't know where we stand on it. > The precise work is held up by: https://github.com/D-Programming-Language/dmd/pull/2480 The GC is due for a redesign / reimplementation. |
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | Meta:
> What if we had an "opDestructure" or "opMatch" or something like that? It could return a tuple and be auto-implemented by the compiler for simple structs/classes. Then users could precisely control how their type can be destructured.
The optional "unapply" method is from the Scala language, and it's more or less what you are suggesting, with a different name (and I agree opSomething sounds like a more fitting name for D). Such opMatch has optional arguments too, because you can match in different ways.
Bye,
bearophile
|
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
> On 7/8/2014 6:01 PM, Mike wrote:
>> On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
>>
>>> 1. Ref Counting
>>>
>>> I believe that ARC is a pipe dream for D, as we've discussed extensively here.
>>> But a ref counted object should work, and would be very attractive, much like
>>> C++'s shared_ptr<T>.
>>
>> How does this differ from std.typecons.RefCounted?
>
> Let me put it this way: users all complain that D doesn't have ref counting. If typecons.RefCounted works, why is this happening? What can be done to convince people that D does ref counting? If it doesn't work, what needs to be done to fix it?
I think the problem is that people like to have reference semantics for ressources but only struct support deterministic destruction, and are value types..
If Unique and RefCounted were a bit more usable people interested in deterministic release (ie. almost everyone) could drop using classes for resources and live happily.
|
July 09, 2014 Re: Opportunities for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > (and I agree opSomething sounds like a more fitting name for D). Added your names: https://issues.dlang.org/show_bug.cgi?id=596 Bye, bearophile |
Copyright © 1999-2021 by the D Language Foundation