The "no gc" crowd

[dennis luehring]

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)