On Sunday, 09 April 2017 at 23:14:08 UTC, Jack Stoufer wrote:
You're missing the forrest for the trees. D needs a general
solution to the problem of GC code in Phobos. This >tackles one
specific area via special case but leaves every other GC
allocation in Phobos, with no way to make >it @safe @nogc. These
will either require the holistic approach eventually or more
special cases.
On Tuesday, 11 April 2017 at 11:39:20 UTC, rjframe wrote:
I have no problem with this specific change, but this method of
solving problems is going to turn D into a horrible language
with all kinds of weird edge cases. I left Python for D mostly
because the language was becoming one hack built on top of
another; it would be nice if D could avoid that path. The
occasional kludge may be necessary, but it shouldn't be normal
or the first thought.
--Ryan
I'm personally belongs to the camp of perfectionists and holists.
But there is bitter experience I want to share, that to be too
purist with such approach just make unable things to happen.
"Release early, release often" isn't just a good words, but real
need, because of lack of early feedback your "perfect" solution
just "SUDDENLY" may not match real use cases, and you don't have
use cases before USE cases :)
So if something going to happen and solve bunch of problem it
should be done (in such way that not prevent more general
holistic solution to be gone into life at some point). The real
issue is only bake transitional process in such way that it
addresses the problems of majority.
So what could be done:
1. Implement this feature; but apply it only if special compiler
flag is specified (the issue I see for this particular feature,
that you should have versioned function declaration, IIRC there
is no possibility to version of an attribute), emit all warnings,
that may you current code clashes with upcoming feature
2. Introduce new flag that disable this feature and remove
previous flag for enabling (from now it would be enabled by
default), make the warnings errors.
3. Remove disabling flag.
(All this describes situation if feature is accepted _as is_ by
language users).
Furthermore it seems to me that D need something like official
binary nightmare releases. It introduces new features in the
manner I have described, but also have a flag like
`-disable-all-fresh-feature` which affect all features at stage
2, for those of us who need industrial compilation. This
"nightmare releases" require however much more frequent major
release cycle (like each 2-3 months), and that isn't bad _per se_.
