On 10/09/2013 04:22 AM, Andrei Alexandrescu wrote:
>
> * Get Robert Schadek's precise GC in. Walter and I have become 101% convinced a precise GC is the one way to go about GC.
>
I would like to claim that work, but the Rainer Schütze wrote that. I know, both german, same initials.

On Wednesday, 9 October 2013 at 09:29:53 UTC, Robert Schadek wrote:
> On 10/09/2013 04:22 AM, Andrei Alexandrescu wrote:
>>
>> * Get Robert Schadek's precise GC in. Walter and I have become 101%
>> convinced a precise GC is the one way to go about GC.
>>
> I would like to claim that work, but the Rainer Schütze wrote that. I
> know, both german, same initials.

From a Levenshtein distance point of view, it's almost your work.

Am 09.10.2013 10:17, schrieb dennis luehring:
> Am 09.10.2013 10:05, schrieb Andrei Alexandrescu:
>> On 10/9/13 12:58 AM, dennis luehring wrote:
>>> Am 09.10.2013 09:51, schrieb Andrei Alexandrescu:
>>>> On 10/9/13 12:01 AM, Mehrdad wrote:
>>>>> On Wednesday, 9 October 2013 at 03:39:38 UTC, Andrei Alexandrescu wrote:
>>>>>> On 10/8/13 4:45 PM, Jonathan M Davis wrote:
>>>>>>> On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
>>>>>>>> I thought about an alternative approach:
>>>>>>>> Instead of using a (yet another) annotation, how about
>>>>>>>> introducing a flag similar to -cov, which would output lines in
>>>>>>>> which the GC is used.
>>>>>>>> This information can be used by an IDE to highlight those lines.
>>>>>>>> Then you could quickly navigate through your performance-critical
>>>>>>>> loop and make sure it's clean of GC.
>>>>>>>
>>>>>>> That sounds like a much less invasive approach no a @nogc attribute.
>>>>>>
>>>>>> Problem is with functions that have no source available.
>>>>>>
>>>>>> Andrei
>>>>>
>>>>>
>>>>> Mangle the @nogc it into the name?
>>>>
>>>> That would work. Then anything that doesn't have @nogc counts as an
>>>> allocation, and the corresponding line will be labeled as such. (I
>>>> suspect that would cause a bunch of false positives in systems that
>>>> don't add @nogc systematically.)
>>>>
>>>>
>>>> Andrei
>>>>
>>>
>>> but maybe combined with adam ruppes idea in thread
>>>
>>> http://forum.dlang.org/post/l322df$1n8o$1@digitalmars.com
>>>
>>> will reduce the false postive amount faster
>>
>> I'm hesitant about stuff that computes function summaries such as
>> __traits(getFunctionsCalled, function) without allowing those summaries
>> to make it into the function's signature or attributes. It makes
>> separate compilation difficult.
>
> what speaks against doing it so (after thinking about it a long long
> time...) i think D needs a proper way of express the function "features"
> compatible with seperated compilation, and there is nothing else as the
> signature - as long as D don't get its own internal object format, and
> still want to be C link compatible
>
>
>

same goes to nothrow, pure, safe, ... and nogc (and possible noarc to even prevent auto reference counting in hierachy if it mabye comes in the future)

On 2013-10-09 05:31, Walter Bright wrote:

> Making this work is fraught with difficulty. It is normal behavior in D
> to create local data with new(), build a data structure, and then cast
> it to shared so it can be transferred to another thread. This will fail
> miserably if the data is allocated on a thread local heap.

I agree with Andrei here. Alternatively perhaps the runtime can move the data to a global pool if it's casted to shared.

-- 
/Jacob Carlborg

On 2013-10-09 07:15, Manu wrote:

> What I want is an option to replace the GC with ARC,

We had an email conversation about ARC when I announced the updated Objective-C support for D. Perhaps it's time make it public. I don't think we came to a conclusion. I had some trouble following it. It was a bit too advanced for me.

-- 
/Jacob Carlborg

On 2013-10-09 09:33, Manu wrote:

> It sounds pretty easy to reach to me. Compiler generating inc/dec ref
> calls can't possibly be difficult. An optimisation that simplifies
> redundant inc/dec sequences doesn't sound hard either... :/
> Is there more to it? Cleaning up circular references I guess... what
> does Apple do?
> It's an uncommon edge case, so there's gotta be heaps of room for
> efficient solutions to that (afaik) one edge case. Are there others?

See my reply to one of your other posts:

http://forum.dlang.org/thread/bsqqfmhgzntryyaqrtky@forum.dlang.org?page=10#post-l33gah:24ero:241:40digitalmars.com

I don't recall the exact issues but there were several issues that were brought up in the email conversation.

-- 
/Jacob Carlborg

On 2013-10-09 09:31, Walter Bright wrote:

> What do you propose?

He wants ARC.

-- 
/Jacob Carlborg

On Tuesday, 8 October 2013 at 22:02:07 UTC, Peter Alexander wrote:
> Just learn where allocations occur and avoid them during development. This leaves you only with accidental or otherwise unexpected allocations.

D is not expected to be a single man project language, isn't it? As I have already said, this implies spending plenty of time on careful reviewing of something that compiler can detect.

> For the accidental allocations, these will come up during profiling (which is done anyway in a performance sensitive program). The profiler gives you the call stack so these are trivial to spot and remove. There are also several other ways to spot allocations (modify druntime to log on allocation, set a breakpoint in the GC using a debugger, etc.) although I don't do these.
>
> You say it is time consuming. In my experience it isn't. General profiling and performance tuning are more time consuming.

1) Profiling is not always possible.
2) Profiling is considerably more time-consuming than getting compiler error.

Time spent on this increases with team size and amount of unexperienced developers in team.

> You may argue that profiling won't always catch accidental allocations due to test coverage. This is true, but then @nogc is only a partial fix to this anyway. It will catch GC allocations, but what about accidental calls to malloc, mmap, or maybe an accidental IO call due to some logging you forgot to remove. GC allocations are just one class of performance problems, there are many more and I hope we don't have to add attributes for them all.

That is why I am askign about @noheap, not about @nogc - GC here is a just a side thing that makes hidden allocations easier. Though question about defining full set of possible system-wide allocation sources is good one and I don't have any reasonable answer for this.

On Tuesday, 8 October 2013 at 22:37:28 UTC, Walter Bright wrote:
> On 10/8/2013 9:22 AM, Dicebot wrote:
>> It is simply "@nogc" which is lacking but absolutely
>> mandatory.
>
> Adding @nogc is fairly simple. The trouble, though, is (like purity) it is transitive. Every function an @nogc function calls will also have to be @nogc. This will entail a great deal of work updating phobos/druntime to add those annotations.

Well I thought in current situation we are pretty much forced to go for attributed inference anyway - this problem is not @nogc specific.

(I actually think making permissive attributes/qualifiers default ones was a very early mistake)

On Tuesday, 8 October 2013 at 23:22:54 UTC, Sean Kelly wrote:
> On Oct 8, 2013, at 3:38 PM, Walter Bright
>> This, of course, is the other problem with @nogc. Having a forest of attributes on otherwise ordinary functions is awfully ugly.
>
> And we already have a forest of attributes on otherwise ordinary functions.

I don't understand why there is such reluctance to have many attributes. I'd gladly accept language with literally hundreds of those if they are orthogonal and useful. That is the very point of using strong typed language - making compiler verify as much assumptions as possible for you. Key problem here is not amount of attributes but that those are opt-in, not opt-out,