Counter-Proposal: restrict & tagged functions

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Sep 3 11:19:24 PDT 2012


On 03-Sep-12 16:32, Piotr Szturmaj wrote:
> 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)
>
> [snip]
>
>> The idea in a nutshell:
>
> [snip]
>
> How the attribute inferring works in this proposal?

Interesting... and it seems like user-defined tags can't be inferred or 
that it would need more thought.

However restrictions can be inferred by observing which things which 
template instance does and the tags of functions it calls. It's exactly 
the same as now but every restriction out of a set (say @safe) now get 
inferred separately.

-- 
Olshansky Dmitry


More information about the Digitalmars-d mailing list