Proposal 2: Exceptions and @nogc

[HaraldZealot via Digitalmars-d]

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_.