Discussion:
Fear of semantic-modifying attributes
(too old to reply)
Myriachan
2015-06-30 23:58:46 UTC
Permalink
Why is there a fear of adding semantic-modifying attributes on the
Committee? I have heard in replies that there is a desire to never add
attributes that cause a semantic change to a program. That is, that
ignoring an attribute is always a reasonable action for an implementation
to take.

The [[noreturn]] attribute, however, is an example of a case that already
causes a semantic change by causing undefined behavior. The below code is
ill-formed if and only if the [[noreturn]] attribute is supported by the
implementation.


#include <cstdio>
#include <type_traits>

[[noreturn]] constexpr void Undefined() noexcept
{
}

int main()
{
return std::integral_constant<int, (Undefined(), 4)>::value;
}



[template.arg.nontype]/1
A *template-argument* for a non-type *template-parameter* shall be a
converted constant expression ([expr.const]) of the type of the
*template-parameter*. ...

[expr.const]/4
A *converted constant expression* of type T is an expression, implicitly
converted to type T, where the converted expression is a constant
expression and the implicit conversion sequence contains only ... (a bunch
of stuff that doesn't apply because the type matches exactly.)

[expr.const]/2.5
A *conditional-expression* e is a *core constant expression* unless the
evaluation of e, following the rules of the abstract machine (1.9), would
evaluate one of the following expressions:
...
— an operation that would have undefined behavior ...;

[dcl.attr.noreturn]/2
If a function f is called where f was previously declared with the noreturn
attribute and f eventually returns, the behavior is undefined. ...


Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Richard Smith
2015-07-01 00:49:11 UTC
Permalink
Post by Myriachan
Why is there a fear of adding semantic-modifying attributes on the
Committee? I have heard in replies that there is a desire to never add
attributes that cause a semantic change to a program. That is, that
ignoring an attribute is always a reasonable action for an implementation
to take.
The [[noreturn]] attribute, however, is an example of a case that already
causes a semantic change by causing undefined behavior.
I don't think a slippery-slope argument is going to work out here; failure
to adhere to principles in some area doesn't necessarily imply those
principles should be abandoned everywhere (there are ways to get around
access control, but the committee is likely to resist adding more, for
instance).
Post by Myriachan
The below code is ill-formed if and only if the [[noreturn]] attribute is
supported by the implementation.
#include <cstdio>
#include <type_traits>
[[noreturn]] constexpr void Undefined() noexcept
{
}
int main()
{
return std::integral_constant<int, (Undefined(), 4)>::value;
}
This is an interesting idea, but a [[noreturn]] constexpr function is
ill-formed, no diagnostic required, because it must either hit an
implementation limit or return.

[dcl.constexpr]/5
For a non-template, non-defaulted constexpr function or a non-template,
non-defaulted, non-inheriting constexpr constructor, if no argument values
exist such that an invocation of the function or constructor could be an
evaluated subexpression of a core constant expression (5.20), or, for a
constructor, a constant initializer for some object (3.6.2), the program is
ill-formed; no diagnostic required.

[expr.const]/2.4
A *conditional-expression* e is a *core constant expression* unless the
evaluation of e, following the rules of the abstract machine (1.9), would
evaluate one of the following expressions:
...
— an expression that would exceed the implementation-defined limits (see
Annex B);

[implimits]/2.35
Recursive constexpr function invocations [512].

[implimits]/2.36
Full-expressions evaluated within a core constant expression [1 048 576].

(Perhaps you could mark a defaulted special member as [[noreturn]] to get
around this...)

[template.arg.nontype]/1
Post by Myriachan
A *template-argument* for a non-type *template-parameter* shall be a
converted constant expression ([expr.const]) of the type of the
*template-parameter*. ...
[expr.const]/4
A *converted constant expression* of type T is an expression, implicitly
converted to type T, where the converted expression is a constant
expression and the implicit conversion sequence contains only ... (a bunch
of stuff that doesn't apply because the type matches exactly.)
[expr.const]/2.5
A *conditional-expression* e is a *core constant expression* unless the
evaluation of e, following the rules of the abstract machine (1.9), would
...
— an operation that would have undefined behavior ...;
[dcl.attr.noreturn]/2
If a function f is called where f was previously declared with the
noreturn attribute and f eventually returns, the behavior is undefined.
...
Melissa
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-07-01 02:05:12 UTC
Permalink
This is an interesting idea, but a [[noreturn]] constexpr function is ill-formed, no diagnostic required, because it must either hit an implementation limit or return.
I don’t see anything that [[noreturn]] isn’t allowed for a function that returns. [dcl.attr.noreturn] only says
[Note: Implementations are encouraged to issue a warning if a function marked [[noreturn]] might return. —end note]
If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undefined.
• an operation that would have undefined behavior as specified in Clauses 1 through 16 of this International Standard
One resolution would be to change that to "Clauses 1 through 16, except Clause [dcl.attr] 7.6” ;)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Richard Smith
2015-07-01 07:27:01 UTC
Permalink
Post by Richard Smith
This is an interesting idea, but a [[noreturn]] constexpr function is
ill-formed, no diagnostic required, because it must either hit an
implementation limit or return.
I don’t see anything that [[noreturn]] isn’t allowed for a function that
returns.
Right, but a constexpr function either returns or hits an implementation
limit, and if it's [[noreturn]] then either way its evaluation is
non-constant, so it's ill-formed NDR.
Post by Richard Smith
[dcl.attr.noreturn] only says
[Note: Implementations are encouraged to issue a warning if a function
marked [[noreturn]] might return. —end note]
If a function f is called where f was previously declared with
the noreturn attribute and f eventually returns, the behavior is undefined.
What Melissa said is that the constant expression evaluation is required
to bail out when the function returns, and reveal the attribute semantics,
A conditional-expression e is a core constant expression unless the
evaluation of e, following the rules of the abstract machine (1.9), would
• an operation that would have undefined behavior as specified in
Clauses 1 through 16 of this International Standard
One resolution would be to change that to "Clauses 1 through 16, *except
Clause [dcl.attr] 7.6*” ;)
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-07-01 08:04:59 UTC
Permalink
Right, but a constexpr function either returns or hits an implementation limit, and if it's [[noreturn]] then either way its evaluation is non-constant, so it's ill-formed NDR.
Ah, I see now. The function itself is defective. The compiler would be within its rights to read [[noreturn]] constexpr, and stop right there. Thanks for bearing with me.

(Diagnosing an error on [[noreturn]] could be considered a semantic effect per se, but using [[noreturn]] to help diagnose the NDR that a constexpr function is never constant is not. In this case, the flexibility within NDR allows the attribute to introduce a build failure.)

It still could be handy to allow undefined behavior on more general attribute contract violation. I don’t suppose the [[noreturn]] sort of argument would apply in many other situations.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-07-01 03:37:36 UTC
Permalink
Post by Myriachan
[[noreturn]] constexpr void Undefined() noexcept
{
}
int main()
{
return std::integral_constant<int, (Undefined(), 4)>::value;
}
The compiler is allowed to compile the code above by ignoring the attribute
and assuming that the constexpr void function did absolutely nothing, as it
must.

The compiler may even print a warning that the [[noreturn]] function did
return.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Continue reading on narkive:
Loading...