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

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.

On Sunday, 2 February 2014 at 00:57:38 UTC, Adam Wilson wrote:
> ...

I often regret that D went so well as "yet another but faster" general-purpose language and is often viewed as such. And this is a niche overloaded with languages. Contrary to that, real-time / barebone stuff is rather narrow niche but there are only few usable languages there (and 0 good languages).

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? It does not introduce any new syntax and should be somewhat in line with existing reference escape analysis.

By the way, Sonke Ludwig has recently named scope + unique/isolated qualifiers as one of more promising D improvements for vibe.d : "having this in the core language would open up a lot of potential for performance and safety improvements and I feel that it needs more advertisement to really reach the decision makers - and of course the general community"

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

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

Thx for giving it a thought though.

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.

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.

On Saturday, 1 February 2014 at 19:11:28 UTC, Adam Wilson wrote:
> On Sat, 01 Feb 2014 09:57:41 -0800, Frustrated <c1514843@drdrb.com> wrote:
>
>> On Saturday, 1 February 2014 at 17:30:54 UTC, Sean Kelly wrote:
>>> On Saturday, 1 February 2014 at 11:40:37 UTC, Frustrated wrote:
>>>>
>>>> And why does Phobos/runtime require the GC in so many cases when
>>>> it could just use an internal buffer? So much effort has been put
>>>> in to make the GC work that it simply has neglected all those
>>>> that can't use it as it is.
>>>
>>> This is the crux of the problem.  It's not so much that D uses garbage collection as that Phobos is built in a way that prevents the reuse of existing buffers.  It becomes much harder to sell the language to a GC averse group if it turns out they can't use the standard library as well.  Though I guess Tango is an option here as a replacement.
>>
>> Right, and because of the mentality that the GC is one size that
>> fits all, phobos got this way. That mentality is still pervasive.
>> I call it laziness.
>>
>> I think that at some point phobos will need to be rewritten...
>> maybe more .net like(there sense of hierarchy and presentation is
>> excellent).  Maybe D needs a proper allocator sub system built in
>> to get to that point?
>
> You do realize that in .NET the BCL is not GC-optional right. It GC-allocates like a fiend. What they have is a monumentally better GC than D. .NET is actually proof that GC's can work quite well in all but the most extreme edge cases.
>
> Effectively what you are saying is ".NET does it well with a GC so we need to rewrite Phobos to not use a GC" ... Um wait, what?
>
> I am not saying to Phobos needs to allocate as much as it does, just that argument itself fails to met a basic standard of logical coherency.

No, you read way more in that than what I said. I am not talking
about the .NET GC(I or I would have said ".NET GC"). You totally
fabricated what you think I "effectively said".

By writing the phobos like .NET, I mean, in terms of .NET's
organization and structure.

Am 02.02.2014 11:44, schrieb Dicebot:
> On Sunday, 2 February 2014 at 00:57:38 UTC, Adam Wilson wrote:
>> ...
>
> I often regret that D went so well as "yet another but faster"
> general-purpose language and is often viewed as such. And this is a
> niche overloaded with languages. Contrary to that, real-time / barebone
> stuff is rather narrow niche but there are only few usable languages
> there (and 0 good languages).

I consider Ada a good one.