Swift does away with pointers == pervasive ARC

Manu via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 16 22:02:32 PDT 2014


On 17 June 2014 13:18, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
>>
>> Hmmm, I still don't buy it,
>
>
> I know, but you also have not responded to my explanation of why. Such as
> the "dec" being required to be inside an expensive exception handler.

Granted. I don't really understand the situation well enough to
comment with any authority. What are the conditions that create the
requirement, or could relax it?

The problem is if something throws, it need an implicit catch to
release the ref right?
nothrow obviously relaxes this requirement. Also in cases where the
ref fiddling was able to be eliminated, which appear to be fairly
numerous.
I don't know enough about other circumstances, but I can see a few
possibilities. Also, just the frequency of pointer copying I see in my
own code is very low, and I would NEVER generate that code in hot
loops.
I find it very hard to convince myself either way without evidence :/

Exceptions are one of my biggest weaknesses. I've never used the
exception handler before, in C++ or D (on XBox360 for instance, the
exception handler is actually broken, generates bad code, and
Microsoft recommend to disable C++ exceptions). I've used scope(exit),
but never in hot code or criticised the codegen.

I can't imagine exceptions would appear in hot code very often/ever?


> Note that Swift seems to not do exceptions (I may be wrong, again, I know
> little about Swift), which is one way to avoid that problem.

I wonder if that was a deliberate choice based on a reaction to this problem?


>> but I'm thinking more that it might
>> benefit from something like a Rust borrowed pointer to maintain safety
>> and performance. You like the 'unsafe escape' defense, so we need to
>> address that, and I think Rust gave us the answer.
>
>
> Have you or anyone you know written any non-trivial programs in Rust and
> tried this out?

No, I intend to have a better play with Rust when I get some time. I
need to break through the syntax barrier first though! ;)
But this is the key innovation in Rust I'm interested to know more
about in practise.


More information about the Digitalmars-d mailing list