On Tuesday, 7 June 2016 at 18:32:05 UTC, Adam D. Ruppe wrote:
> On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
>> You can also add:
>>
>>    @nogc:
>>
>> at the top, too. It isn't necessary to tediously annotate every function.
>
> @nogc:
>
> struct Foo {
>         int* a() { return new int; }
> }

Are you trying to say that you shouldn't be allowed to do that? I get an error when I actually call x.a().

@nogc:

struct Foo {
        int* a() { return new int; }
}

void main()
{
	Foo x;
	auto y = x.a();
}

On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
> Add:
>
>    @safe:
>
> at the top of your D module and you'll find the @system code.

Sure, that's easy to do in my code, but we were talking about 3rd party code. Plus the template problem comes up again: no one should be annotating their templates anything but maybe @property. So in practice, because you recommend (correctly) that everything should be a template, there's nothing to grep.

> You can also add:
>
>    @nogc:
>
> at the top, too. It isn't necessary to tediously annotate every function.

Are you sure? @nogc is not like @safe in that it has a corresponding negating version to cancel the top level out. If I have @nogc at the top, there's no way to declare an allocating function in that file, therefore you have to use @nogc {}. This is why some have proposed hacks like !@nogc.

On 07.06.2016 20:43, jmh530 wrote:
>>
>
> Are you trying to say that you shouldn't be allowed to do that? I get an
> error when I actually call x.a().
>
> @nogc:
>
> struct Foo {
>          int* a() { return new int; }
> }
>
> void main()
> {
>      Foo x;
>      auto y = x.a();
> }

You'll get the same error for this program:

@nogc:

struct Foo {
    int x;
    int* a() { return &x; }
}

void main(){
    Foo x;
    auto y = x.a();
}

On Tuesday, 7 June 2016 at 18:00:43 UTC, Ola Fosheim Grøstad wrote:
> There was actually a person from an academic OS research team that wrote about adopting Go (probably changing it) for an experimental OS implementation. Someone on the Go team thought it was a good idea and also that they could do it using garbage collection...

side note: garbage-collected OS is possible, and written, and is working. Inferno.

On Tuesday, 7 June 2016 at 18:54:25 UTC, Timon Gehr wrote:
>
> You'll get the same error for this program:
>

Also, it doesn't help to make the struct or member functions templates because it's no different than appending @nogc everywhere. You would need some kind of !@nogc as others have pointed out.

On Tuesday, 7 June 2016 at 18:43:12 UTC, jmh530 wrote:
> Are you trying to say that you shouldn't be allowed to do that? I get an error when I actually call x.a().

The colon attributes do NOT extend inside aggregates. Putting @nogc: at the top did not affect my function a(), because it was inside a struct.

Real world code tends to have a lot of structs and such, so the claim that you can just slap whatever: at the top doesn't stand up to scrutiny, even disregarding the other problems like lack of inversion or backward default.


I wrote more about this a couple months ago here: http://arsdnet.net/this-week-in-d/2016-apr-17.html

I have actually softened my position somewhat since then, but still hold to the key point: the default behavior means apathy ruins the feature. Use a library written by someone who didn't care to write @nogc, but nevertheless didn't actually use the gc? too bad.

On 6/7/16 2:43 PM, jmh530 wrote:
> On Tuesday, 7 June 2016 at 18:32:05 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
>>> You can also add:
>>>
>>>    @nogc:
>>>
>>> at the top, too. It isn't necessary to tediously annotate every
>>> function.
>>
>> @nogc:
>>
>> struct Foo {
>>         int* a() { return new int; }
>> }
>
> Are you trying to say that you shouldn't be allowed to do that? I get an
> error when I actually call x.a().
>
> @nogc:
>
> struct Foo {
>         int* a() { return new int; }
> }
>
> void main()
> {
>     Foo x;
>     auto y = x.a();
> }

That's because main is @nogc. If you did:

void main()
{
    Foo x;
    auto y = x.a();
}

@nogc:

struct Foo {
        int* a() { return new int; }
}

it would work. Adam's point is that putting @nogc: at the top doesn't mark everything @nogc.

-Steve

On Tuesday, 7 June 2016 at 18:59:13 UTC, ketmar wrote:
> side note: garbage-collected OS is possible, and written, and is working. Inferno.

Yes, the Go guys was involved. So it is possible yes, but why would you want to have a garbage collected kernel? What do you gain from it? Extra trouble is what you gain from it.

On 6/7/16 1:19 PM, Wyatt wrote:
> On Tuesday, 7 June 2016 at 08:05:58 UTC, Russel Winder wrote:
>> So instead of debating this endlessly, I think this is about the tenth
>> time this has come up in the last two years, why doesn't a group of
>> people who know about GC algorithms get together and write a new one?
>
> In addition to the other answers, it's worth noting that most every good
> modern GC algorithm I can think of requires barriers.  Walter has
> repeatedly and emphatically declared that D will not have barriers, so
> we're kind of SoL on on that front.  Java and Go don't have that problem.

So you're saying one of the barriers to adoption is no barriers...

-Steve

On Tuesday, 7 June 2016 at 19:07:03 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 18:59:13 UTC, ketmar wrote:
>> side note: garbage-collected OS is possible, and written, and is working. Inferno.
>
> Yes, the Go guys was involved. So it is possible yes, but why would you want to have a garbage collected kernel? What do you gain from it? Extra trouble is what you gain from it.

'cause it simplifies memory management, on all levels... if we'll switch to microkernel architecture. but this is very off-topic.