hi there,

I think that D compiler needs -nogc switch to fully disable gc for a project, and document of phobos also needs a friendly way to list-out all @nogc API.

we already have -betterC, and betterC disabled GC, why we could not have a standalone option for doing this?



----
binghoo dang

On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:
> hi there,
>
> I think that D compiler needs -nogc switch to fully disable gc for a project, and document of phobos also needs a friendly way to list-out all @nogc API.
>
> we already have -betterC, and betterC disabled GC, why we could not have a standalone option for doing this?
>
>
>
> ----
> binghoo dang

you can do this with a druntime switch or by calling GC.disable  in your main()

On Tuesday, 11 June 2019 at 08:08:14 UTC, Basile B. wrote:
> On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:
>> hi there,
>>
>> I think that D compiler needs -nogc switch to fully disable gc for a project, and document of phobos also needs a friendly way to list-out all @nogc API.
>>
>> we already have -betterC, and betterC disabled GC, why we could not have a standalone option for doing this?
>>
>>
>>
>> ----
>> binghoo dang
>
> you can do this with a druntime switch or by calling GC.disable
>  in your main()

the druntime switch is "--DRT-gc=gc:manual". You pass it the compiled program after its own args.

On Tuesday, 11 June 2019 at 08:16:31 UTC, Basile B. wrote:
> On Tuesday, 11 June 2019 at 08:08:14 UTC, Basile B. wrote:

>>
>> you can do this with a druntime switch or by calling GC.disable
>>  in your main()
>
> the druntime switch is "--DRT-gc=gc:manual". You pass it the compiled program after its own args.

thanks, I know this from dlang.org. But this is not useful when trying to write @nogc code for a project.

We need to make sure we use only @nogc API when writing code, not when running the app.


Thanks!


----
binghoo dang

On Tuesday, 11 June 2019 at 08:05:31 UTC, dangbinghoo wrote:
> I think that D compiler needs -nogc switch to fully disable gc for a project,
>
LDC -nogc?

> and document of phobos also needs a friendly way to list-out all @nogc API.
>
+1
people who are interested only in betterC/nogc shouldn't see documentation to api that they are not suitable.

On Tuesday, 11 June 2019 at 08:59:01 UTC, dangbinghoo wrote:
> We need to make sure we use only @nogc API when writing code, not when running the app.

That's what the @nogc annotation does, statically forces you to only use other @nogc stuff via compiler errors.

On Tuesday, 11 June 2019 at 10:24:05 UTC, KnightMare wrote:
> people who are interested only in betterC/nogc shouldn't see documentation to api that they are not suitable.

I've considered doing that before, but it is actually impossible to get right in the general case due to attribute inference.

Consider `map`, for example. If you map a nogc function, map is nogc. But if not, it isn't - it depends on what function the user passes to it. So the documentation can not know for sure.

On Tuesday, 11 June 2019 at 12:42:03 UTC, Adam D. Ruppe wrote:
> On Tuesday, 11 June 2019 at 10:24:05 UTC, KnightMare wrote:
>> people who are interested only in betterC/nogc shouldn't see documentation to api that they are not suitable.
>
> I've considered doing that before, but it is actually impossible to get right in the general case due to attribute inference.
>
> Consider `map`, for example. If you map a nogc function, map is nogc. But if not, it isn't - it depends on what function the user passes to it. So the documentation can not know for sure.

imo problem with nogc/betterc is more deeper.
lets suppose we already have rcstring class and man want to write func that returns slice of it.
char[] someStrProcess(...) {
  rcstring tmp = "hello" ~ rcreadln; // somehow we got rcstring
  return tmp[5..$-5];
}
with current slise (struct{.ptr, .length}) we have a problem - data of tmp we'll be freed at function exit and current slice will ref to garbage. so compiler should forbid such situation.
this is not very well coz people read four current books where the slices were colorfully described, but for some reason a person cannot use them. they will come to forum and will ask another clarifying questions.

ok. we should returns some another slice(struct{.rcarray,.offset,.length}) which knows about RC:
rcslice<char> someStrProcess(...) {
  rcstring tmp = "hello" ~ rcreadln; // somehow we got rcstring
  return tmp[5..$-5]; // I dont want return whole string just part of it
  // should I return new rcstring as tmp.substr( 5, tmp.length-10 )?
  // should we lose slices at all?
}
and this is something new that not described yet. well, it will be.
but maybe better write compiler that will returns rcslice as native new style slice char[] that knows about RC? some lang that mix of D and Swift which already used RC as ARC with familiar from book syntax.
and tada! we have two different language in one compiler, we have two different RT with one compiler. maybe it will be Phobos and Deimos.

On Tuesday, 11 June 2019 at 12:40:39 UTC, Adam D. Ruppe wrote:
> On Tuesday, 11 June 2019 at 08:59:01 UTC, dangbinghoo wrote:
>> We need to make sure we use only @nogc API when writing code, not when running the app.
>
> That's what the @nogc annotation does, statically forces you to only use other @nogc stuff via compiler errors.

yeah, @nogc does the job. But the problem is that, you need to mark all functions, classes, everything you write to manually marked, so if compiler supports -nogc, it will helps great.


-----
binghoo dang

On Tuesday, 11 June 2019 at 14:44:20 UTC, KnightMare wrote:
Stroustrup said about C++ (not exactly quote. I translated it from my lang not English):
since C and C ++ will be used by the same people on
many years, the differences between languages should be
either minimal or maximal to minimize the amount
mistakes and misunderstandings.

so this 2 modes - gc & nogc - of D must follow the same principle.
DBC with RC will be new lang.
so, will they be very similar or very different?