void BlockingFunc() // All functions are considered to be blocking by default
{
}
[[ensures(nonblocking)]] void NonblockingFunc()
{
}
[[ensures(nonblocking)]] void MyFunc()
{
BlockingFunc(); // error: "nonblocking" attribute not specified
conforms(nonblocking)
{
BlockingFunc(); // no error
}
NonblockingFunc(); // no error
}
[[ensures(nonblocking)]] void MyFunc()
{
conform_cast<nonblocking>( BlockingFunc() ); // no error
}
Thiago,
Thanks for the words of support.
Thinking about this a little more, in order to mix well with old code, it needs a way to override the absence of the specifier or attribute in the way that "const_cast" and "mutable" override "const". I was thinking that blocks (scopes) of code within a function could be tagged as conformant with the specifier or attribute:
void BlockingFunc() // All functions are considered to be blocking by default
{
}
[[ensures(nonblocking)]] void NonblockingFunc()
{
}
[[ensures(nonblocking)]] void MyFunc()
{
BlockingFunc(); // error: "nonblocking" attribute not specified
conforms(nonblocking)
{
BlockingFunc(); // no error
}
NonblockingFunc(); // no error
}
nonblocking
" is attribute then disabling it should be too.[[ensures(nonblocking)]] void MyFunc()
{
int x = [[ignore(nonblocking
)]] funcA();
[[ignore(nonblocking)]]
{
funcB();
funcV();
}
}
On sexta-feira, 15 de julho de 2016 15:03:53 PDT Derek Hofmann wrote:
> That's a good catch, inkwizyt.
>
> Besides "nonblocking", another tag people might want to use is "reentrant".
> And there's already a topic about it:
Also "safe" or "untrusted".
Basically, the proposal should be for generic tags, such that the compiler
should produce a diagnostic when calling an untagged function from a tagged
one (or vice-versa), or assigning a tagged variable to an untagged one (or
vice-versa)
[[require(tagname)]] void func1()
{
//Can only call functions that have `tagname`
//func1 is considered to have `tagname`
}
[[allow(tagname)]] void func2()
{
//Cannot call functions that have `!tagname`.
//func2 is considered to have `tagname`.
}
[[require(!tagname)]] void func3
{
//Can only call functions that have `!tagname`.
//func3 is considered to have `!tagname`.
}
[[allow(!tagname)]] void func4
{
//Cannot call functions that have `tagname`
//func4 is considered to have `!tagname`.
}
For me, I'm mainly concerned about whether a function is guaranteed safe (nonblocking) or not guaranteed safe. Being able to distinguish between two substates of "not guaranteed safe" (unknown vs. guaranteed unsafe) adds a little value but a lot of complexity to the specification.
What's a situation where 3 levels per tag is needed?
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/q8bMB4ZTl4E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c38a4b14-964b-4603-baff-37e9f7abbebd%40isocpp.org.
For me, I'm mainly concerned about whether a function is guaranteed safe (nonblocking) or not guaranteed safe. Being able to distinguish between two substates of "not guaranteed safe" (unknown vs. guaranteed unsafe) adds a little value but a lot of complexity to the specification.
What's a situation where 3 levels per tag is needed?
On quinta-feira, 14 de julho de 2016 16:49:38 PDT Thiago Macieira wrote:
> > Another person had a similar idea but thought a more general solution of
> > allowing custom type modifiers might be better:
> > http://allievi.sssup.it/techblog/archives/705
> >
> > Has anything like this been proposed?
> Maybe you can widen your proposal to something like attribute
> [[ensures(xxx)]], which can only call other functions that have the same
> xxx in their [[ensures(...)]] declaration. This would allow for different
> tags, not just "nonblocking".
Uh... which is what you had said.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/44f5d65c-8c10-449b-baf1-ec71c815e099%40isocpp.org.