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