On 23 February 2015 at 20:24, Jakob Ovrum via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
>>
>> On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
>>
>> <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> I have no idea where to start.
>>>
>>>
>>>
>>> Start by making a ref counted type and see what the pain points are.
>>
>>
>> All my ref counting types fiddle with the ref in every assignment, or every function call and return. Unless the language has some sort of support for ref counting, I don't know how we can do anything about that.
>
>
> There's no move constructor in D, so how did you manage that?

I wrote it above.

struct Thing
{
  T *instance;

  this(this) { Inc(instance); }
  ~this() { Dec(instance); }

  // this would really assist RC when 'scope' is inferred liberally.
  this(this) scope {}
  ~this() scope {}
}

In this case, rc is part of the instance; no reason to separate it when RC is not a generalised concept. Of course the structure can be generalised and fiddled/meta-ed to suit purpose in any number of ways. Inc's and Dec's galore!

I'm not sure what a move constructor would give me over this.

On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
>> 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
>> bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is
>> not an option for D.
>
> This is going to sound really stupid... but do people actually use
> exceptions regularly?

It doesn't matter if they do or not. It's a feature of D, and has to be supported. The only time it won't matter is if the intervening code is all 'nothrow'.


> You say that's a terminal case? Generating code to properly implement
> a decrement chain during unwind impacts on the non-exceptional code
> path?

Since you don't believe me :-), write some shared_ptr code in C++ using your favorite compiler, compile it, and take a look at the generated assembler. I've asked you to do this before.

It's necessary to understand how exception unwinding works in order to pontificate about ARC.


>> 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores
>> memory safety concerns.
> What makes RC implicitly unsafe?

You already know the answer - saving pointers to the RC object's payload that then outlive the RC'd object.

On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
> O[…]
> This is going to sound really stupid... but do people actually use
> exceptions regularly?
> I've never used one. When I encounter code that does, I just find it
> really annoying to debug. I've never 'gotten' exceptions. I'm not sure
> why error codes are insufficient, other than the obvious fact that
> they hog the one sacred return value.
> D is just a whisker short of practical multiple-return-values. If we
> cracked that, we could use alternative (superior?) error state return
> mechanisms. I'd be really into that.
[…]

Return codes for value returning functions only work if the function returns a pair, the return value and the error code: it is generally impossible to work with return values that serve the purpose of return value and error code. C got this fairly wrong, Go gets it fairly right.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
> value and error code. C got this fairly wrong, Go gets it fairly right.

It's the one feature about Go that makes Go code look really ugly... So I guess this is a very subjective issue. Posix is actually pretty consistent by returning "-1", even as a pointer, but if you don't write pure Posix code it becomes confusing.

On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
> On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
>> O[…]
>> This is going to sound really stupid... but do people actually use
>> exceptions regularly?
>> I've never used one. When I encounter code that does, I just find it
>> really annoying to debug. I've never 'gotten' exceptions. I'm not sure
>> why error codes are insufficient, other than the obvious fact that
>> they hog the one sacred return value.
>> D is just a whisker short of practical multiple-return-values. If we
>> cracked that, we could use alternative (superior?) error state return
>> mechanisms. I'd be really into that.
> […]
>
> Return codes for value returning functions only work if the function
> returns a pair, the return value and the error code: it is generally
> impossible to work with return values that serve the purpose of return
> value and error code. C got this fairly wrong, Go gets it fairly right.

You wouldn't need new syntax (though I think multiple returns would be a nice addition), I think you can compile try/catch exception syntax into error codes internally.

On 2/22/15 9:53 PM, Manu via Digitalmars-d wrote:
> On 23 February 2015 at 14:11, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:
>>>
>>> I can easily visualise a way forward with RC.
>>
>>
>> Then do it. Frankly it seems to me you're doing anything you possibly can to
>> talk yourself out of doing work.
>
> Excellent technique to immediately invalidate everything someone says.
> Thanks for that.

It's not immediate - it's a pattern our dialog has followed for years. Essentially I haven't yet managed to communicate with you.

> You dismissed absolutely everything I said, and then imply that I have
> no right to comment unless I do it myself.
> It's got nothing to do with doing work. ARC (or something like it) is
> almost religiously opposed. We can't even have a reasonable
> conversation about it, or really explore it's implications before
> someone (that ideally know's what they're doing) thinks about writing
> code. There's no room for progress in this environment.

I think RC is an important tool on our panoply. More so than Walter. But I have to say you'd do good to understand his arguments better; it doesn't seem you do.

> What do you want me to do? I use manual RC throughout my code, but the
> experience in D today is identical to C++. I can confirm that it's
> equally terrible to any C++ implementation I've used. We have no tools
> to improve on it.

Surely you have long by now written something similar to std::shared_ptr by now. Please paste it somewhere and post a link to it, thanks. That would be a fantastic discussion starter.

> And whatever, if it's the same as C++, I can live with it. I've had
> that my whole career (although it's sad, because we could do much
> better).
> The problem, as always, is implicit allocations, and allocations from
> 3rd party libraries. While the default allocator remains incompatible
> with workloads I care about, that isolates us from virtually every
> library that's not explicitly written to care about my use cases.
> That's the situation in C++ forever. We're familiar with it, and it's
> shit. I have long hoped we would move beyond that situation in D
> (truly the #1 fantasy I had when I first dove in to D 6 years back),
> but it's a massive up-hill battle to even gain mindshare, regardless
> of actual implementation. There's no shared vision on this matter, the
> word is basically "GC is great, everyone loves it, use an RC lib".

It doesn't seem that way to me at all. Improving resource management is right there on the vision page for H1 2015. Right now people are busy fixing regressions for 2.067 (aiming for March 1; probably we won't make that deadline). In that context, posturing and stomping the ground that others work for you right now is in even more of a stark contrast.

> How long do we wait for someone to invent a fantastical GC that solves
> our problems and works in D?

This elucubration belongs only to you. Nobody's waiting on that. Pleas read http://wiki.dlang.org/Vision/2015H1 again.

> I think it's practically agreed that no
> known design can work, but nobody wants to bite the bullet and accept
> the fact.

I don't understand where this perception is coming from.

> We need to admit we have an impassable problem, and then maybe we can
> consider alternatives openly. Obviously, it would be disruptive, but
> it might actually work... which is better than where we seem to be
> heading (with a velocity of zero).

Please forgive people who are working on getting 2.067 out for not making things you need their top priority right now.

> The fact is, people who are capable of approaching this problem in
> terms of actual code will never even attempt it until there's
> resounding consensus that it's worth exploring.

Could you please let me know how we can rephrase this paragraph on http://wiki.dlang.org/Vision/2015H1:

=============
Memory Management

We aim to improve D's handling of memory. That includes improving the garbage collector itself and also making D eminently usable with limited or no use of tracing garbage collection. We aim to make the standard library usable in its entirety without a garbage collector. Safe code should not require the presence of a garbage collector.
=============

Could you please let me know exactly what parts you don't understand or agree with so we can change them. Thanks.


Andrei

On 2/23/15 3:27 AM, Walter Bright wrote:
> On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
>>> 1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in
>>> time and
>>> bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS.
>>> This is
>>> not an option for D.
>>
>> This is going to sound really stupid... but do people actually use
>> exceptions regularly?
>
> It doesn't matter if they do or not. It's a feature of D, and has to be
> supported. The only time it won't matter is if the intervening code is
> all 'nothrow'.
>
>
>> You say that's a terminal case? Generating code to properly implement
>> a decrement chain during unwind impacts on the non-exceptional code
>> path?
>
> Since you don't believe me :-), write some shared_ptr code in C++ using
> your favorite compiler, compile it, and take a look at the generated
> assembler. I've asked you to do this before.
>
> It's necessary to understand how exception unwinding works in order to
> pontificate about ARC.

BTW: http://asm.dlang.org

Andrei

On 2/23/15 4:30 AM, Russel Winder via Digitalmars-d wrote:
> On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
>> O[…]
>> This is going to sound really stupid... but do people actually use
>> exceptions regularly?
>> I've never used one. When I encounter code that does, I just find it
>> really annoying to debug. I've never 'gotten' exceptions. I'm not sure
>> why error codes are insufficient, other than the obvious fact that
>> they hog the one sacred return value.
>> D is just a whisker short of practical multiple-return-values. If we
>> cracked that, we could use alternative (superior?) error state return
>> mechanisms. I'd be really into that.
> […]
>
> Return codes for value returning functions only work if the function
> returns a pair, the return value and the error code: it is generally
> impossible to work with return values that serve the purpose of return
> value and error code. C got this fairly wrong, Go gets it fairly right.

Urgh. Product types masquerading as sum types. Give me a break will ya. -- Andrei

On Mon, 2015-02-23 at 10:08 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
> 
> Urgh. Product types masquerading as sum types. Give me a break will ya. -- Andrei
> 

Uuurrr…. no. As of today I program with the stuff and it works. Coming from Java and Python, I am an exceptions oriented person, but Go has internal consistency on it's attitude to error reporting and you get used to it. Actually, the obsession with error handling at the point of occurrence does lead to getting systems that are less prone to unexpected errors. This is pragmatism not theory. And being honest most programmers would not know what product or sum types were. Nor would they care. Even if perhaps they ought to.

When I worked with C, I abhorred the, to me, dreadful error codes system. Go really does allow it to work without the same pain.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2/23/15 10:50 AM, Russel Winder via Digitalmars-d wrote:
> On Mon, 2015-02-23 at 10:08 -0800, Andrei Alexandrescu via Digitalmars-d
> wrote:
> […]
>>
>> Urgh. Product types masquerading as sum types. Give me a break will ya.
>> -- Andrei
>>
>
> Uuurrr…. no. As of today I program with the stuff and it works. Coming
> from Java and Python, I am an exceptions oriented person, but Go has
> internal consistency on it's attitude to error reporting and you get
> used to it. Actually, the obsession with error handling at the point of
> occurrence does lead to getting systems that are less prone to
> unexpected errors. This is pragmatism not theory. And being honest most
> programmers would not know what product or sum types were. Nor would
> they care. Even if perhaps they ought to.
>
> When I worked with C, I abhorred the, to me, dreadful error codes
> system. Go really does allow it to work without the same pain.

This is a misunderstanding. I was referring to Go's confusion of sum types with product types. -- Andrei