Walter Bright:

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

In this thread I have asked for just tuples, not pattern matching (I have just said that tuples design should not make it very hard to add a basic but nice form of pattern matching later in the switch statement).

Regarding NotNull (your point 8), I think what's more important is to make it statically impossible for the programmer to dereference a null for a nullable type. (To do this some languages use pattern matching, that forces the programmer to handle both cases (null and not null), and in the case of not null, the programmer is handling something similar to a NotNull).

Bye,
bearophile

Some minor disagreements:

On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
> 2. Unique References
>
> unique_ptr<T> is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type.

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

> 3. 'ref' means 'borrowed', to use Rust's terminology
>
> We're almost there with this. This means better escape analysis, too.

Last time we talked about it during dconf you have mentioned doing necessary escape analysis for borrowing semantics is too complicated to consider :) Ad if you don't mean transitive, you shouldn't refer to Rust borrowing terminology as any ownership type is normally transitive there.

> 5. Precise and Concurrent GC
>
> There's been a lot of work on this, but I don't know where we stand on it.

I have started work on porting the CDGC to D2, have compilable version (that was easy thanks to earlier Sean work) but updating implementation to match new druntime and pass tests will take quite some time.

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

I'd state it differently: "Marketing fuss about goroutines is the killer feature of Go" :) It does not have any fundamental advantage over existing actor model and I doubt it will matter _that_ much.

> 8. NotNull!T type
>
> For those that want a non-nullable reference type. This should be doable as a library type.

I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.

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?

For me the simple "works or not" test question is "can you do reference counted exceptions?". Right now it is impossible AFAIK.

On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
>
>
> 3. 'ref' means 'borrowed', to use Rust's terminology
>
> We're almost there with this. This means better escape analysis, too.

IMO this is not good, because it should be applicable for pointers, classes and slices, too (and structs containing any of them, of course). If you use `ref` with these, an extra layer of indirection is introduced, which also changes the semantics, e.g. for non-const pointers the original pointer can suddenly be overwritten. `scope` is much better suited for borrowing, because it's orthogonal to `ref`.

> 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>.
>
>
> 2. Unique References
>
> unique_ptr<T> is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type.

std.type.Unique needs to be fleshed out, or a different type created (`Owned`?). The current `Unique` accepts only pointers and classes, but should really accept anything, as with borrowing. Desirable features include:
* explicit or implicit move-semantics
* a way to remove uniqueness (e.g. after sending a value to a different thread, it no longer needs to be Unique)
* compiler support for verifying that the value it's constructed from _is_ actually unique
* deterministic destruction
* allocator support (because of the previous point)
* usable inside aggregates
* applicable to any type; a move overwrites the rhs with the type's init value

Borrowing can elegantly solve many of the problems with Unique and RC:
* Unique and RefCounted should be implicitly borrowable (opBorrow?)
* library routines pervasively take their inputs as `scope`; no need to provide different overloads for Unique, RefCounted, normal values, or even user-implemented wrappers => abstracts away the implementation details while retaining safety

On Wednesday, 9 July 2014 at 07:10:09 UTC, Jacob Carlborg wrote:
> 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.

As far as I know, there's no reason we can't add pattern matching to switch or final switch or both. There's no ambiguity because right now it's not possible to switch on structs or classes. See Kenji's DIP32 for syntax for tuples that could be leveraged.

On 07/08/2014 11:22 PM, Walter Bright wrote:
> ...
>
> 3. 'ref' means 'borrowed', to use Rust's terminology
>
> We're almost there with this. This means better escape analysis, too.
> ...

What makes you think that 'ref' is a good match for this functionality, and how are we almost there with this?

>
>
> 8. NotNull!T type
>
> For those that want a non-nullable reference type. This should be doable
> as a library type.
>

No.

On Wednesday, 9 July 2014 at 13:06:06 UTC, Marc Schütz wrote:
> std.type.Unique needs to be fleshed out, or a different type created (`Owned`?).

There is an `Isolated` in vibe.d which is more tuned for usage with std.concurrency (its vibe.d fork to be specific)

On 08/07/2014 23:40, Remo wrote:
>> What about the already present std.typecons.Unique?
>
> Unfortunately there are a lot of /+Doesn't work yet+/ comments in
> std.typecons.Unique code.

I think it was written a long time ago. I think much of those parts will work now. I'm slowly going through them and will make more PRs, here's the first one, to disable postblit:

https://github.com/D-Programming-Language/phobos/pull/2308

On Wed, Jul 09, 2014 at 12:47:30AM -0700, Walter Bright via Digitalmars-d wrote:
> 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:
[...]
> >>>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.

I would, except that I'm unsure of exactly what is needed in said design.  Are we just trying to nail down the exact semantics of 'scope'? Or are we looking at implementational issues (possible compiler performance hits)? Or both? Or something else altogether? Do we need to account for (what little exists of) the current implementation? Speaking of which, what *is* the current extent of the implementation of 'scope'? I assume it isn't just a no-op, since I see it applied to delegate parameters every now and then?


T

-- 
What's a "hot crossed bun"? An angry rabbit.

Dicebot:

> I don't know where it comes from but non-nullable reference type has ZERO value if it is not the default one.

This article talks about switching to NotNull on default in real (small) Java projects (you have to add a @NonNullByDefault at package level to change the default):

http://blog2.vorburger.ch/2014/07/java-8-null-type-annotations-in-eclipse.html

Bye,
bearophile