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.
