July 09, 2014
On Tuesday, 8 July 2014 at 22:21:43 UTC, bearophile wrote:
> Walter Bright:
>
>> but it doesn't go so far as creating a Unique!T type.
>
> What about the already present std.typecons.Unique?
>
>
> In your list I'd like to add another point:
> 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").
>
> Bye,
> bearophile

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.
July 09, 2014
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?
July 09, 2014
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:

>
>
> 7. "D-Routines" - goroutines for D
>
> Goroutines are the killer feature of Go for a number of sensible people. We pretty much have this already with fibers, but what is lacking is a scheduler, which will take some effort, and a "Channel" type, which should be easy.
>

vibe.d has something similar, which could go into the standard library IMHO:

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d
July 09, 2014
On 7/8/2014 3:21 PM, bearophile wrote:
> Walter Bright:
>
>> but it doesn't go so far as creating a Unique!T type.
>
> What about the already present std.typecons.Unique?

It's not good enough.


> In your list I'd like to add another point:
> 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").

The list isn't about things that would be nice to add to D, it's about fairly critical issues with large impact we need to address. More on tuples and pattern matching are not critical issues.

July 09, 2014
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.

July 09, 2014
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?
July 09, 2014
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?

Well, for starters RefCounted doesn't work with classes. That
needs to be implemented. I'm not sure what was problematic about
implementing it for classes though (anyone reading know?).

Secondly, a lot of things need to be extracted from std.grabbag
(AKA std.typecons) and put in modules with names that are much
more obvious. Nobody thinks to check "typecons" (whatever that
means)* but it contains some of the most useful general purpose
features in Phobos. It has Tuple, Unique, RefCounted, Scoped,
Nullable, and more all buried away in an unexpected module.

I propose just stealing C++'s structure when possible (so
std.tuple and std.memory for starters).


* Yes, I know it means Type Constructors. That isn't clear the
first time someone reads the name though.
July 09, 2014
On Wednesday, 9 July 2014 at 03:18:54 UTC, Brad Anderson wrote:
> Well, for starters RefCounted doesn't work with classes. That
> needs to be implemented. I'm not sure what was problematic about
> implementing it for classes though (anyone reading know?).

idk if this is what the Phobos devs were thinking, but my own attempts have hit a few snags:

1) double indirection with the naive solution: struct { Object o; int refcount; }. Pretty easily fixed by emplacing the class though so no big deal but phobos didn't seem to attempt this so maybe that was a problem there.

2) It messes up implicit casting. And this is a big deal because I don't think there's a solution: alias this can help with the base class, but can't handle the multiple requirements of classes that implement several interfaces.

If you alias this to the payload, it would accomplish everything... but then the reference is no longer counted, allowing it to escape and still point to freed memory.

Multiple alias this is prolly a solution to the problem.

> Secondly, a lot of things need to be extracted from std.grabbag
> (AKA std.typecons) and put in modules with names that are much
> more obvious. Nobody thinks to check "typecons"

yea I think most people don't even know this stuff exists.
July 09, 2014
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:

My question was sincere, I really wanted to know more about the differences  RefCounted and what you proposed.

> 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?

From what I've observed, I don't think users are complaining that D doesn't do ref counting.  I believe they are complaining that D doesn't do pervasive automatic reference counting.  RefCounted can't be used with D's built-in types, right?

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).

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.

>  If [std.typecons.RefCounted] doesn't work, what needs to be done to fix it?

RefCounted or any other library solution can't be used with D's built-in types, right?  Also, it forces users to change their patterns and idioms.  I consider these drawbacks, and don't see any solution except to provide an alternative GC implementation.

Mike

July 09, 2014
On Wednesday, 9 July 2014 at 04:12:50 UTC, Mike wrote:
> My question was sincere, I really wanted to know more about the differences  RefCounted and what you proposed.

shared_ptr supports multi-threading, weak pointers and destructors.

> If RefCounted is intended to have shared_ptr<T> semantics,

Nowhere near the same semantics:

http://en.cppreference.com/w/cpp/memory/shared_ptr

http://dlang.org/phobos/std_typecons.html#.RefCounted