On Saturday, 1 September 2012 at 16:20:14 UTC, Dmitry Olshansky
wrote:
On 01-Sep-12 17:01, Adam D. Ruppe wrote:
On Saturday, 1 September 2012 at 12:39:41 UTC, Dmitry
Olshansky wrote:
I'd say
@nogc:
at the top and deal is sealed.
BTW don't forget a @yesgc would be good to counter it. We need
a way to turn off each attribute to use this pattern best.
What I see with this @nogc proposal is that that problem it
tries to solve (and tool used to do so) is far more interesting
and general.
Namely the problem is to specify that some functions can call
only specific subset of functions and able to use only specific
subset of language features. It's more far reaching then just
gc, one may want to get @noblocking or @async attribute to
statically check e.g. that GUI thread can't ever block.
(it would however require to identify API calls that don't
block, not possible on every OS, might entail some wrappers
etc. but is very desirable)
To peek at what's more there that you can get this way see C++
AMP on why restricting a block of code or function is useful
e.g. here by Herb Sutter (including nice demo!):
http://www.youtube.com/watch?v=HK9rJFpX32Y
BTW @safe is in the same bucket, it does allow only to call
@safe & @trusted (read as "subset of ") functions and use a
subset of language features.
Actually exactly the same goes for pure (noglobal whatever) you
just state this piece of code can't use this language feature
(global variables, static variables, you name it), same for
nothrow.
And not long ago David Nadlinger showed that function level
trusted doesn't help much with templates that are @trusted for
their own code, but need normal safety guarantee from foreign
code brought by parameters. Thus restriction has to be able to
work on a block scope too.
So what I want with this? I want to bring together C++ AMP
restrict and @safe/@trusted/@system/pure/nothrow machinery in
one clean and user-extensible future-proof feature.
The idea in a nutshell:
<snip details>
I skipped the details but I do agree with the general sentiment.
This long post begs the question - Why a general annotation
mechanism isn't enough to justify adding so much complexity to
the language?
Me thinks that simply tagging malloc/alloca/GC.allocate/etc..
with a _user defined_ annotation should be sufficient without the
need to introduce all of the above syntax to the language. In
fact, I have a vague memory of reading about green/red marking of
code via templates in plain old c++. No extra syntax required.
Here's the link:
http://www.artima.com/cppsource/codefeaturesP.html
