On Tuesday, 15 April 2014 at 19:57:59 UTC, monarch_dodra wrote:
> I have an issue related to adding an extra attribute: Attributes of non-template functions. Currently, you have to mark most functions as already pure, nothrow and @safe. If we are adding another attribute. Code will start looking alike this:
>
> int someTrivialFunction(int i) @safe pure nothrow @nogc;
>
don't forget final ;)

On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
>>> Obj-C only uses ARC for a minority of the objects.
>> Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
>
> And what about all allocated items?

What do you mean?

>>> A UI is a good use case for ARC. A UI doesn't require high performance.
>> I've written video processing/players on iOS, they all use blocks and reference
>> counting, including to do date/time processing per frame. All while using RC
>> network buffers. And it works quite smoothly.
>
> And did you use ref counting for all allocations and all pointers?

Yes.

> There's no doubt that ref counting can be used successfully here and there, with a competent programmer knowing when he can just convert it to a raw pointer and use that.

The compiler treats pointers to NSObject-derived differently than pointers to structs and raw bytes. There is no need to know, you just use them like normal pointers, and the compiler inserts the retain/release calls for you.

But I did not use structs. I only used structs for network packet overlays. I still created an object that contained the struct to enjoy the benefits of the memory management system.

> And remember that if you have exceptions, then all the dec code needs to be in exception unwind handlers.

I haven't really used exceptions, but they automatically handle the reference counting.

-Steve

On 4/17/2014 10:41 AM, Dicebot wrote:
> On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
>>> With current limitations @nogc is only useful to verify that embedded code which
>>> does not have GC at all does not use any GC-triggering language features before
>>> it comes to weird linker errors / rt-asserts. But that does not work good either
>>> because of next problem:
>>
>> Remember that @nogc will be inferred for template functions. That means that
>> whether it is @nogc or not will depend on its arguments being @nogc, which is
>> just what is needed.
>
> No, it looks like I have stated that very wrong because everyone understood it
> in completely opposite way. What I mean is that `put()` is NOT @nogc and it
> still should work. Same as weakly pure is kind of pure but allowed to mutate its
> arguments, proposed "weakly @nogc" can only call GC via functions directly
> accessible from its arguments.

I don't see value for this behavior.


>> I know that you bring up the array literal issue and gc a lot, but this is
>> simply not a major issue with @nogc. The @nogc will tell you if it will
>> allocate on the gc or not, on a case by case basis, and you can use easy
>> workarounds as necessary.
>
> Beg my pardon, I have overstated this one indeed but temptation was just too
> high :) On actual topic - what "case by case" basis do you have in mind? There
> are no cases mentioned in spec when literals are guaranteed to not allocated
> AFAIK. Probably compiler developers know them but definitely not me.

That's why the compiler will tell you if it will allocate or not.

On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
> On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
>>>> Obj-C only uses ARC for a minority of the objects.
>>> Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
>>
>> And what about all allocated items?
>
> What do you mean?

Can you call malloc() ?

>>>> A UI is a good use case for ARC. A UI doesn't require high performance.
>>> I've written video processing/players on iOS, they all use blocks and reference
>>> counting, including to do date/time processing per frame. All while using RC
>>> network buffers. And it works quite smoothly.
>>
>> And did you use ref counting for all allocations and all pointers?
>
> Yes.

You never used malloc? for anything? or stack allocated anything? or had any pointers to anything that weren't ref counted?

How did that work for printf?


>> There's no doubt that ref counting can be used successfully here and there,
>> with a competent programmer knowing when he can just convert it to a raw
>> pointer and use that.
>
> The compiler treats pointers to NSObject-derived differently than pointers to
> structs and raw bytes.

So there *are* regular pointers.

> There is no need to know, you just use them like normal
> pointers, and the compiler inserts the retain/release calls for you.

I know that with ARC the compiler inserts the code for you. That doesn't make it costless.


> But I did not use structs. I only used structs for network packet overlays. I
> still created an object that contained the struct to enjoy the benefits of the
> memory management system.
>
>> And remember that if you have exceptions, then all the dec code needs to be in
>> exception unwind handlers.
>
> I haven't really used exceptions, but they automatically handle the reference
> counting.

I know it's done automatically. But you might be horrified at what the generated code looks like.

On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
> On 4/17/2014 10:41 AM, Dicebot wrote:
>> On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
>>>> With current limitations @nogc is only useful to verify that embedded code which
>>>> does not have GC at all does not use any GC-triggering language features before
>>>> it comes to weird linker errors / rt-asserts. But that does not work good either
>>>> because of next problem:
>>>
>>> Remember that @nogc will be inferred for template functions. That means that
>>> whether it is @nogc or not will depend on its arguments being @nogc, which is
>>> just what is needed.
>>
>> No, it looks like I have stated that very wrong because everyone understood it
>> in completely opposite way. What I mean is that `put()` is NOT @nogc and it
>> still should work. Same as weakly pure is kind of pure but allowed to mutate its
>> arguments, proposed "weakly @nogc" can only call GC via functions directly
>> accessible from its arguments.
>
> I don't see value for this behavior.

It's a formal promise that the function won't do any GC work *itself*, only indirectly if you pass it something that implicitly does heap allocation.

E.g. you can implement some complicated function foo that writes to a user-provided output range and guarantee that all GC usage is in the control of the caller and his output range.

The advantage of having this as language instead of documentation is the turtles-all-the-way-down principle: if some function deep inside the call chain under foo decides to use a GC buffer then it's a compile-time-error.

1986 - Brad Cox and Tom Love create Objective-C, announcing "this language has all the memory safety of C combined with all the blazing speed of Smalltalk." Modern historians suspect the two were dyslexic.

( http://james-iry.blogspot.no/2009/05/brief-incomplete-and-mostly-wrong.html )

On Thu, 17 Apr 2014 15:55:10 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
>> On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>
>>> On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
>>>>> Obj-C only uses ARC for a minority of the objects.
>>>> Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
>>>
>>> And what about all allocated items?
>>
>> What do you mean?
>
> Can you call malloc() ?

Of course. And then I can wrap it in NSData or NSMutableData.

>>>>> A UI is a good use case for ARC. A UI doesn't require high performance.
>>>> I've written video processing/players on iOS, they all use blocks and reference
>>>> counting, including to do date/time processing per frame. All while using RC
>>>> network buffers. And it works quite smoothly.
>>>
>>> And did you use ref counting for all allocations and all pointers?
>>
>> Yes.
>
> You never used malloc? for anything? or stack allocated anything? or had any pointers to anything that weren't ref counted?
>
> How did that work for printf?

I didn't exactly use printf, iOS has no console. NSLog logs to the xcode console, and that works great.

But we used FILE * plenty. And I've had no problems.

>>> There's no doubt that ref counting can be used successfully here and there,
>>> with a competent programmer knowing when he can just convert it to a raw
>>> pointer and use that.
>>
>> The compiler treats pointers to NSObject-derived differently than pointers to
>> structs and raw bytes.
>
> So there *are* regular pointers.

Of course, all C code is valid Objective-C code.

>> There is no need to know, you just use them like normal
>> pointers, and the compiler inserts the retain/release calls for you.
>
> I know that with ARC the compiler inserts the code for you. That doesn't make it costless.

I'm not saying it's costless. I'm saying the cost is something I didn't notice performance-wise.

But my point is, pointers are pointers. I use them the same whether they are ARC pointers or normal pointers (they are even declared the same way), but the compiler treats them differently.

>>> And remember that if you have exceptions, then all the dec code needs to be in
>>> exception unwind handlers.
>>
>> I haven't really used exceptions, but they automatically handle the reference
>> counting.
>
> I know it's done automatically. But you might be horrified at what the generated code looks like.
>

Perhaps a reason to avoid exceptions :) I generally do anyway, even in D.

-Steve

On Thursday, 17 April 2014 at 19:55:08 UTC, Walter Bright wrote:
> I know that with ARC the compiler inserts the code for you. That doesn't make it costless.

No, but Objective-C has some overhead to begin with, so it matters less. Cocoa is a very powerful framework that will do most of the weight-lifting for you, kinda like a swiss army knife. In the same league as Python. Slow high level, a variety of highly optimized C functions under the hood. IMHO Python and Objective-C wouldn't stand a chance without their libraries.

> I know it's done automatically. But you might be horrified at what the generated code looks like.

Apple has put a lot of resources into ARC. How much slower than manual RC varies, some claim as little as 10%, others 30%, 50%, 100%. In that sense it is proof-of-concept. It is worse, but not a lot worse than manual ref counting if you have a compiler that does a very good job of it.

But compiled Objective-C code looks "horrible" to begin with… so I am not sure how well that translates to D.

On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
> I'm not saying it's costless. I'm saying the cost is something I didn't notice
> performance-wise.

You won't with FILE*, as it is overwhelmed by file I/O times. Same with UI objects.

On Thu, 17 Apr 2014 16:47:04 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
>> I'm not saying it's costless. I'm saying the cost is something I didn't notice
>> performance-wise.
>
> You won't with FILE*, as it is overwhelmed by file I/O times. Same with UI objects.

OK, you beat it out of me. I admit, when I said "Video processing/players with network capability" I meant all FILE * I/O, and really nothing to do with video processing or networking.

-Steve