Swift does away with pointers == pervasive ARC

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 07:07:11 PDT 2014


On Tue, 17 Jun 2014 01:02:32 -0400, Manu via Digitalmars-d  
<digitalmars-d at puremagic.com> wrote:

> 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?

This is the issue, because the release can do a LOT of shit. It could  
release a whole tree of objects, it could start throwing its own  
exceptions.

It's like doing a lot of stuff inside a signal handler. Possible, but very  
hairy.

A possible solution might be to defer the releasing until the exception is  
caught, and have the catch statement call all the releases. Just speaking  
 from ignorance, I don't know if this solves Walter's concern. The stack  
unwinding still would have to figure all this stuff out. But if we just  
add these calls to a release pool that is drained at the catch point,  
maybe it helps solve the problem.

BTW, as a general response, I don't think swift is as proven yet as  
Objective C. As has been pointed out many times, one of the greatest (and  
arguably worst) parts of Objective C is that any C code is valid Objective  
C code. This means, you can instantly go into unsafe C mode if you need  
the performance.

 From what I can tell, swift does NOT allow that, there will need to be  
some sort of bridge there. I think it will make code that uses pure  
objective C calls and methods more pleasant to write (i.e. UI and  
framework code). I'm not sure how I feel about it yet, I have yet to use  
Swift. But I am hesitant to say that swift will be a step forward  
performance-wise. Apple claims it is, we shall see.

-Steve


More information about the Digitalmars-d mailing list