On Tue, 22 Apr 2014 14:15:35 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>> Again with the straw man!
>
> If you really believe you can make a performant ARC system, and have it be memory safe, feel free to write a complete proposal on it.

I hope you can understand that from this discussion, I'm not to motivated to devote time on it. Not that I could do it anyway :)

Generally, when investing a lot of time and energy into something, you want to make sure the market is there first...

-Steve

On Tuesday, 22 April 2014 at 18:38:28 UTC, Steven Schveighoffer wrote:
> I hope you can understand that from this discussion, I'm not to motivated to devote time on it. Not that I could do it anyway :)

Do it anyway.

This is such a fun topic and many would be entertained by the ensuing excruciating inquisitorial process.

On Tue, 22 Apr 2014 14:43:04 -0400, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:

> On Tuesday, 22 April 2014 at 18:38:28 UTC, Steven Schveighoffer wrote:
>> I hope you can understand that from this discussion, I'm not to motivated to devote time on it. Not that I could do it anyway :)
>
> Do it anyway.

I mean not like I can't because I don't want to or don't have time, but can't as in I lack the skill set :) It's interesting to debate, and I get the concepts, but I am not a CPU/cache guy, and these things are really important to get right for performance, since ref counting would be used frequently.

-Steve

On 2014-04-22 17:52:27 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> Even doing it the way they have seems unnecessarily complex, given that
> iOS 64-bit was brand new.

Perhaps it's faster that way due to some caching effect. Or perhaps it's to be able to have static constant string objects in the readonly segments.

Apple could always change their mind and add another field for the reference count. The Modern runtime has non-fragile classes, so you can change the base class layout breaking ABI compatibility.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
> On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>>> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright <newshound2@digitalmars.com>
>>> wrote:
>>>> The thing is, with iOS ARC, it cannot be statically guaranteed to be memory
>>>> safe.
>>>
>>> So?
>>
>> If you see no value in static guarantees of memory safety, then what can I say?
>
> Seriously, the straw man arguments have to stop.
>
> There is plenty of valuable D code that is not guaranteed memory safe.

Memory safety is not a strawman. It's a critical feature for a modern language, and will become ever more important.


> For example, druntime.

Nobody expects a GC's guts to be guaranteed memory safe. But they do expect the interface to it to be memory safe, and using GC allocated data to be memory safe, and being able to write performant memory safe code.

And by memory safe, I don't mean hand verified. I mean machine verified.

On Tuesday, 22 April 2014 at 18:48:04 UTC, Steven Schveighoffer wrote:
> I mean not like I can't because I don't want to or don't have time, but can't as in I lack the skill set :) It's interesting to debate, and I get the concepts, but I am not a CPU/cache guy, and these things are really important to get right for performance, since ref counting would be used frequently.

I think RC performance unfortunately is very hardware dependent. So, it involves testing, benchmarking etc… Still, I think these discussions are good because they are opportunities to look at what others do (like Objective-C) which is educational (at least for me).

The trouble I have with ref counting is that the future of HW is uncertain, but that can be held against GC too. Take for instance Phi with 80 cores and a crossbar interconnects (?), how does that affect memory management? Unfortunately I have no personal experience with Phi so my take on it is rather vague…

But if ARC takes a long time to get right I think one should consider effects of upcoming HW when considering for/against. Maybe Go's CSP model is better for Phi. Maybe not.  I don't know, but I think it is an interesting topic,  because 4-8 cores is not going to be enough in the next decade. I think…

On 4/22/2014 11:38 AM, Steven Schveighoffer wrote:
> Generally, when investing a lot of time and energy into something, you want to
> make sure the market is there first...

Ironic, considering that nobody but me believed there was a market for D before it existed :-)

I do believe there is a market for ARC in D. What I don't believe are the various claims about how insignificant its costs are, and I'm not so willing to give up on memory safety.

On Tue, 22 Apr 2014 15:02:05 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/22/2014 11:28 AM, Steven Schveighoffer wrote:
>> On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>
>>> On 4/22/2014 6:18 AM, Steven Schveighoffer wrote:
>>>> On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright <newshound2@digitalmars.com>
>>>> wrote:
>>>>> The thing is, with iOS ARC, it cannot be statically guaranteed to be memory
>>>>> safe.
>>>>
>>>> So?
>>>
>>> If you see no value in static guarantees of memory safety, then what can I say?
>>
>> Seriously, the straw man arguments have to stop.
>>
>> There is plenty of valuable D code that is not guaranteed memory safe.
>
> Memory safety is not a strawman. It's a critical feature for a modern language, and will become ever more important.

No, a straw man argument is when you imply that I am arguing from a position that is similar to my actual position, but obviously flawed. Then proceed to attack the straw man.

Example:

    A: Sunny days are good.
    B: If all days were sunny, we'd never have rain, and without rain, we'd have famine and death.

At no time did I ever say I see no value in static guarantees of memory safety. But I also see value in ref counting for performance and memory purposes in NON memory-safe code.

-Steve

On Tue, 22 Apr 2014 15:10:31 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/22/2014 11:38 AM, Steven Schveighoffer wrote:
>> Generally, when investing a lot of time and energy into something, you want to
>> make sure the market is there first...
>
> Ironic, considering that nobody but me believed there was a market for D before it existed :-)

Sure but I'm not prepared to generate a new language over this. If you won't accept it, there's no point in making it.

In other words, YOU are the market ;)

*disclaimer* I am in no shape to actually make such a proposal/change, and probably it would come out horribly if I tried, implementation-wise. I simply am trying to convince you that it would be a valuable addition to D so others may see an opportunity there.

> I do believe there is a market for ARC in D. What I don't believe are the various claims about how insignificant its costs are, and I'm not so willing to give up on memory safety.

You don't have to. Just make ARC not @safe.

-Steve

On 2014-04-22 19:02:05 +0000, Walter Bright <newshound2@digitalmars.com> said:

> Memory safety is not a strawman. It's a critical feature for a modern language, and will become ever more important.

What you don't seem to get is that ARC, by itself, is memory-safe.

Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe.

I'm pretty confident that had I continued my work on D/Objective-C we'd now be able to interact with Objective-C objects using ARC in @safe code. I was planning for that. Objective-C actually isn't very far from memory safety now that it has ARC, it just lacks the @safe attribute to enable compiler verification.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca