On 2/2/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 2. Work on Phobos to see what can be done about avoiding unnecessary allocation. Most likely we'll need to also add a @nogc flag.

See Johannes'es pull here: https://github.com/D-Programming-Language/dmd/pull/1886

Where he comments:

```
Note: This could also be a start to implement a -nogc parameter which
would check a whole module not to use the GC. This is less intrusive
than a @nogc attribute.
```

On 02/02/2014 05:55 PM, Andrei Alexandrescu wrote:
>
> I think of the following foci for the first half of 2014:
>
> 1. Add @nullable and provide a -nullable compiler flag to verify it. The
> attribute is inferred locally and for white-box functions (lambdas,
> templates), and required as annotation otherwise. References not
> annotated with @nullable are statically enforced to never be null.

- I assume that also, references annotated with @nullable are statically enforced to never be dereferenced?

- how to eg. create an array of nullable references? struct Nullable!T{ @nullable T t; alias t this; } Nullable!T[] foo; ? I think that would cause problems with IFTI.

On 02/02/2014 06:55 PM, Timon Gehr wrote:
> struct Nullable!T

struct Nullable(T). Non-uniformity of declaration and usage...

Am Sun, 2 Feb 2014 18:36:29 +0100
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 2/2/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > 2. Work on Phobos to see what can be done about avoiding unnecessary allocation. Most likely we'll need to also add a @nogc flag.
> 
> See Johannes'es pull here: https://github.com/D-Programming-Language/dmd/pull/1886
> 
> Where he comments:
> 
> ```
> Note: This could also be a start to implement a -nogc parameter which
> would check a whole module not to use the GC. This is less intrusive
> than a @nogc attribute.
> ```

The last iteration actually implements -nogc and the pull request also provides almost everything needed for @nogc. The attribute should probably be added in a second pull request as I expect more discussions there.

On Sun, 02 Feb 2014 06:48:28 -0800, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 02.02.2014 15:11, schrieb Adam D. Ruppe:
>> On Sunday, 2 February 2014 at 11:23:56 UTC, JR wrote:
>>> I *seem* to remember reading here that you and Walter were
>>> increasingly growing to favor ARC, but I can't find the post.
>>
>> Personally, I think ARC is a waste of time and none of the arguments
>> I've seen for it are convincing. Improving the Gc implementation would
>> be a much bigger win.
>
> It might be that ARC will be a solution given the recent work in Objective-C, ParaSail, Rust and the misterious M#.
>
> I was even surprised to discover that Cedar actually used RC with a GC just for collecting cycles.
>
> What I don't like is using Objective-C as a poster child for ARC, because the only reason it exists, is that Apple engineers weren't able to write a GC for Objective-C that didn't core dump left and right.
>
> Apple of course sold the history in a different way.
>
> --
> Paulo

I just want to point out that in the comments of Joe Duffy's latest post on M# he explicitly stated that M# is still C# semantics, and specifically he says that all existing C# code will compile with M#, since ARC would by very fact of it's nature require the language semantics to change, it's extremely unlikely that M# will use ARC. Especially since they have access to a GC guru. For a ridiculously easy example, what do you do when one object implements .Dispose() and another one does not?

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 2/2/14, Johannes Pfau <nospam@example.com> wrote:
> The last iteration actually implements -nogc and the pull request also provides almost everything needed for @nogc.

Excellent. 2014 is looking great so far. :>

On 2/2/2014 8:55 AM, Andrei Alexandrescu wrote:
> 1. Add @nullable and provide a -nullable compiler flag to verify it. The
> attribute is inferred locally and for white-box functions (lambdas, templates),
> and required as annotation otherwise. References not annotated with @nullable
> are statically enforced to never be null.

I want to clarify that @nullable would be a storage class, NOT a type constructor. This means it will apply to the variable itself, not its type.

For example:

@nullable T* p;
auto q = p;      // q is a T*, not @nullable

In a way, it would work much like ref, which is also a storage class and not a type constructor.

On 2/2/2014 9:30 AM, Namespace wrote:
> Sounds good. But why @nullable instead of C# choice of "Type?" ?

Let me rephrase that as "why use a storage class rather than a type constructor?"

An excellent question.

One of the big problems with a type constructor is we've already got a number of them - const, immutable, shared, inout. These and their conversions have taken quite a while for people to get comfortable with, and there are still some issues in the language arising from their interactions.

Adding another type constructor will double the number of cases. I worry that D would collapse under the strain. This applies as well to type constructors for "borrowed", etc.

On the other hand, D took the risky leap into the unknown by making 'ref' a storage class rather than a type constructor (in C++ it's a type constructor). This has turned out to be a satisfying win. I suspect it will be for @nullable, too, though we have to work through the cases to find out for sure.

On 2/2/2014 9:55 AM, Timon Gehr wrote:
> - how to eg. create an array of nullable references? struct Nullable!T{
> @nullable T t; alias t this; } Nullable!T[] foo; ? I think that would cause
> problems with IFTI.

@nullable being a storage class, this couldn't be done with @nullable just as you cannot create an array of 'ref' types.

+1 on making Phobos GC-free.

On Sunday, 2 February 2014 at 07:35:21 UTC, Andrei Alexandrescu wrote:
> On 2/1/14, 10:00 PM, Frank Bauer wrote:
>> On Sunday, 2 February 2014 at 05:41:53 UTC, Andrei Alexandrescu wrote:
>>> Sure. While you're young typecheck this:
>>>
>>> class A {
>>>   auto stuff() { ...; return this; }
>>> }
>>>
>>>
>>> Andrei
>>
>> It would be a Borrowed!A, I would say, no matter how an A is allocated.
>> A GC!A, an ARC!A and an Owning!A convert equally well to a Borrowed!A.
>> As long as the Borrowed!A is in use (i.e. scope) after stuff() returns,
>> the A object must not be freed (compiler enforced). Would that make sense?
>
> No.
>
> What I'm driving at is that right now the type is A, as is in a variety of other situations. It would be a whole different language that would be wholly incompatible with D.
>
>
> Andrei

Why is that? I propose the new memory regime to be 100% compatible with all existing D code. It is way more powerful than anything scope can do. And it seems a lot less work to me than going through GC optimization and custom allocator tracing hell.

Let's see how far we can get if we require none of the existing D code to break.

Example: this is current D code that runs unchanged and with the same semantics under the new memory regime. GC(T) and Borrowed(T) remain under the hood:

class A {
    A foo() { return this; }   // returns Borrowed!A
}

void main () {
    A m1 = new A;   // m1 is a GC!A
    A m2 = m1;      // m2 is a Borrowed!A
    A m3;           // Borrowed!A
    m3 = m1;        // fine: assignment from GC!A to Borrowed!A
    m3 = bar(m1);   // fine: m1 converted from GC!A to Borrowed!A, assignment from Borrowed!A to Borrowed!A
    m3 = bar(m2);   // fine: m2 already Borrowed!A, assignment from Borrowed!A to Borrowed!A
    m1 = new A;     // fine: can reasssign GC!A although there are outstanding references
    m1 = m2;        // fine: can reassign GC!A to a Borrowed!A
}

A bar(A a) {        // takes and returns Borrowed!A
    A b1 = a;
    return b1;
}

Now here it comes: if, on the other hand, I replace the first 'new' with, say e.g., 'newOwning' (or '~', whatever), I get GC-free code:

A m1 = newOwning A; // m1 is an Owning!A, allocating on the heap and freeing when it goes out of scope

Then these lines above would be in error:

    m1 = new A;     // error: can't reassign to m1 because m2 and m3 still referencing m1 (same for newOwning)
    m1 = m2;        // error: can't assign Borrowed!A to Owning!A

ARC(T) could be implemented similarly.

Nothing changes one bit for those who want to use the GC as before. ARC(T) and Owning(T) would be *ADDED* on top of the existing language spec.

Emplacement new, as Adam mentioned, is not a problem: you always get to the emplaced object with a Borrowed!T. The underlying memory is managed separately and automatically as a GC!M, ARC!M or Owning!M (M could be an array of bytes, e.g.).