Counter-Proposal: restrict & tagged functions

[foobar]

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