February 02, 2014
Am 02.02.2014 10:03, schrieb Martin Cejp:
> On Sunday, 2 February 2014 at 05:12:05 UTC, Frank Bauer wrote:
>> On Sunday, 2 February 2014 at 04:23:35 UTC, Adam Wilson wrote:
>>> Maybe, but my point is that even with no allocations in phobos, you'd
>>> have to verify that ALL the libraries you use don't GC allocate.
>>> That's why so many people in the ARC camp want to make it the only GC
>>> system in D. Multiple GC systems increase your cognitive load
>>> considerably.
>>
>> Good point. What we DON'T want is a library that comes in
>> MySuperLib-GC, MySuperLib-ARC, MySuperLib-Owning and
>> MySuperLib-Borrowed flavors.
>>
>> But I don't think that is necessary.
>>
>> A library function would typically take arguments by reference aka as
>> a Borrowed(T). GC(T), ARC(T) and Owning(T) convert equally well to
>> Borrowed(T). So somebody who uses only GC(T) in her code could use the
>> library just as easily as someone who prefers Owning(T). The library
>> would be compatible with the two, because it does not own the
>> (reference to the) passed object. GC(T) or Owning(T) at the call site
>> would free the object automatically (at the next collection cycle or
>> when leaving the scope). Everybody is happy!
>>
>> All that is left for the caller is to choose whether she wants to use
>> a library that uses GC *internally*. Interaction is possible in every
>> combination:
>>
>> 1. I use GC(T),     the library uses GC(T) internally     -> works
>> (with GC),
>> 2. I use Owning(T), the library uses GC(T) internally     -> works
>> (with GC),
>> 3. I use GC(T),     the library uses Owning(T) internally -> works
>> (with GC),
>> 4. I use Owning(T), the library uses Owning(T) internally -> works
>> (w/o GC).
>
> This exists. It's called C++.
>
> I've pretty much given up on GC and do all my allocations in the
> real-time path manually. In a game, there shouldn't be that much stuff
> to allocate once live, anyway.

The problem with C++ is the C traps that live within and are the cause of many C++ gotchas, as described by Bjarne on the "The Design and Evolution of C++" book.

--
Paulo
February 02, 2014
On Sunday, 2 February 2014 at 14:12:39 UTC, Adam D. Ruppe wrote:
> On Sunday, 2 February 2014 at 10:53:36 UTC, Dicebot wrote:
>> What do you think about my `scope` proposal? It does not introduce any new syntax and should be somewhat in line with existing reference escape analysis.
>
> What's the link to your proposal? I think I've read it before and liked it (scope would rock) but not sure it is the same thing on my mind.

There is no DIP for it, if you mean that. rvalue reference DIP has been implying it but mostly it is just short generalization for info already spread around the docs: http://forum.dlang.org/post/uopnrbrjwkxgejbcojxa@forum.dlang.org

It boils down to storage class that binds lifetime of entity to scope + qualifier that guarantees that no references/pointers to that data can be possibly stored at the end of scope in question. May need attribute inference to become usable with Phobos though.

I have originally wanted to write it down in DIP form but at that time Andrei has said that implementing scope is out of question. Wondering if his opinion has changed :)
February 02, 2014
> I have originally wanted to write it down in DIP form but at that time Andrei has said that implementing scope is out of question. Wondering if his opinion has changed :)
What? When did he say that? And why?
February 02, 2014
On Sunday, 2 February 2014 at 07:35:21 UTC, Andrei Alexandrescu wrote:
> 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.

A == Borrowed!A in my view. Consider this:

class A { A foo() { return this; } }

A a;

void crashy() {
   ubyte[__traits(classInstanceSize, A)] Abuffer;
   auto localA = emplace!A(Abuffer);

   a = localA.foo();
}


That's obviously wrong, when crashy returns, a is dead... but it has no way of knowing that.

Let's consider we wrote a nice little Owned!T. Internally, it keeps that buffer, disables postblit, frees in the destructor and might have a release method to transfer ownership. All stuff we can do in the library today.


Owned!A a;
void crashy() {
   Owned!A localA = Owned!A();
   a = localA; // prohibited, this(this) is annotated with @disable
   a = localA.foo(); // should ALSO be prohibited, cannot convert A to Owned!A
}


The class object itself doesn't know how it is stored. If it returns this, it MUST assume it is borrowed unless it explicitly allocates a new thing.

For all it knows, it was emplaced into a static array or malloced. A == Borrowed!A. typeof(this) == A.




So, what about the global a up there? I think there's two solutions:

1) ideally, Owned!A has something like this:

scope A borrow() { return payload; }
alias borrow this;

A a = localA; // legal, A is a local variable in the same or inner scope
globalA = localA; // illegal, since borrow returns scope, it isn't allowed to escape


2) a worse but perhaps doable option would be

A globalA; // illegal, non-local variable must not be borrowed

struct foo {
  A a; // now foo is itself considered a borrowed reference type so the rules apply to it
}

GC!A globalA; // ok cool



What's interesting about this is we could, in theory (and I've done a limited proof of concept), implement it in the library using a static assert in RTInfo!

anyway i g2g might talk more later
February 02, 2014
On Sunday, 2 February 2014 at 14:37:50 UTC, Namespace wrote:
>> I have originally wanted to write it down in DIP form but at that time Andrei has said that implementing scope is out of question. Wondering if his opinion has changed :)
> What? When did he say that? And why?

Well, wording was a bit different but from DIP36 discussion thread (http://forum.dlang.org/post/ylebrhjnrrcajnvtthtt@forum.dlang.org):

> It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.

+

> > You consider "scope" a new language feature?
> Yes.

I can be wrong but I have interpreted this as "no plans to actually implement scope in any forseeable future"
February 02, 2014
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
February 02, 2014
On 2/2/14, 2:53 AM, Dicebot wrote:
> On Sunday, 2 February 2014 at 07:35:21 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> What do you think about my `scope` proposal?

I think that's more likely to be made to work.

Andrei
February 02, 2014
On 2/2/14, 3:23 AM, JR wrote:
> On Sunday, 2 February 2014 at 05:30:02 UTC, Andrei Alexandrescu wrote:
>> On 2/1/14, 8:18 PM, Frank Bauer wrote:
>>> On Sunday, 2 February 2014 at 03:38:03 UTC, Andrei Alexandrescu wrote:
>>>> Whoa, this won't work without an explosion in language complexity.
>>>>
>>>> Andrei
>>>
>>> Only daydreaming ...
>>
>> No, it's a nightmare.
>>
>> Andrei
>
> So, going forward, what would you say is the preferred direction to
> strive toward?
>
> I *seem* to remember reading here that you and Walter were increasingly
> growing to favor ARC, but I can't find the post. (Memory bitrot on my
> part is more than likely.)

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.

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.

3. Work on adding tracing capabilities to allocators and see how to integrate them with the language and Phobos.

4. Work on the core language and druntime to see how to seamlessly accommodate alternate GC mechanisms such as reference counting.


Andrei

February 02, 2014
On Sunday, 2 February 2014 at 16:55:35 UTC, Andrei Alexandrescu
wrote:
> On 2/2/14, 3:23 AM, JR wrote:
>> On Sunday, 2 February 2014 at 05:30:02 UTC, Andrei Alexandrescu wrote:
>>> On 2/1/14, 8:18 PM, Frank Bauer wrote:
>>>> On Sunday, 2 February 2014 at 03:38:03 UTC, Andrei Alexandrescu wrote:
>>>>> Whoa, this won't work without an explosion in language complexity.
>>>>>
>>>>> Andrei
>>>>
>>>> Only daydreaming ...
>>>
>>> No, it's a nightmare.
>>>
>>> Andrei
>>
>> So, going forward, what would you say is the preferred direction to
>> strive toward?
>>
>> I *seem* to remember reading here that you and Walter were increasingly
>> growing to favor ARC, but I can't find the post. (Memory bitrot on my
>> part is more than likely.)
>
> 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.
>
> 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.
>
> 3. Work on adding tracing capabilities to allocators and see how to integrate them with the language and Phobos.
>
> 4. Work on the core language and druntime to see how to seamlessly accommodate alternate GC mechanisms such as reference counting.
>
>
> Andrei

Sounds like a step in the right direction. By having the nogc,
phobos could be progressively converted and one can verify when
modules, functions, and aggregates are gc dependent.

February 02, 2014
On Sunday, 2 February 2014 at 16:55:35 UTC, Andrei Alexandrescu wrote:
> On 2/2/14, 3:23 AM, JR wrote:
>> On Sunday, 2 February 2014 at 05:30:02 UTC, Andrei Alexandrescu wrote:
>>> On 2/1/14, 8:18 PM, Frank Bauer wrote:
>>>> On Sunday, 2 February 2014 at 03:38:03 UTC, Andrei Alexandrescu wrote:
>>>>> Whoa, this won't work without an explosion in language complexity.
>>>>>
>>>>> Andrei
>>>>
>>>> Only daydreaming ...
>>>
>>> No, it's a nightmare.
>>>
>>> Andrei
>>
>> So, going forward, what would you say is the preferred direction to
>> strive toward?
>>
>> I *seem* to remember reading here that you and Walter were increasingly
>> growing to favor ARC, but I can't find the post. (Memory bitrot on my
>> part is more than likely.)
>
> 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.
>
> 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.
>
> 3. Work on adding tracing capabilities to allocators and see how to integrate them with the language and Phobos.
>
> 4. Work on the core language and druntime to see how to seamlessly accommodate alternate GC mechanisms such as reference counting.
>
>
> Andrei

Sounds good. But why @nullable instead of C# choice of "Type?" ?
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19