[Config] Patch: clang implemented N3276 decltype
Clang implemented N3276 decltype (which does not require type-completeness of a function call expression) Attached a patch for boost/config/compiler/clang.hpp. BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name? Regards, Michel
On 3/6/2012 5:10 PM, Michel Morin wrote:
Clang implemented N3276 decltype (which does not require type-completeness of a function call expression) Attached a patch for boost/config/compiler/clang.hpp.
Cool!
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long. :-P -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote:
Clang implemented N3276 decltype (which does not require type-completeness of a function call expression) Attached a patch for boost/config/compiler/clang.hpp.
Cool!
Very nice.
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE? - Daniel
On 3/6/2012 6:27 PM, Daniel Walker wrote:
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote:
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE?
Ambiguous. Does that mean that decltype support is incomplete or that decltype doesn't force type-completeness? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Mar 6, 2012, at 11:09 PM, Eric Niebler wrote:
On 3/6/2012 6:27 PM, Daniel Walker wrote:
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote:
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE?
Ambiguous. Does that mean that decltype support is incomplete or that decltype doesn't force type-completeness?
BOOST_NO_INCOMPLETE_DECLTYPE means the compiler does not support incomplete decltypes; i.e. it does not support decltype expressions that are incomplete types. - Daniel
On 3/6/2012 8:45 PM, Daniel Walker wrote:
On Mar 6, 2012, at 11:09 PM, Eric Niebler wrote:
On 3/6/2012 6:27 PM, Daniel Walker wrote:
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote:
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE?
Ambiguous. Does that mean that decltype support is incomplete or that decltype doesn't force type-completeness?
BOOST_NO_INCOMPLETE_DECLTYPE means the compiler does not support incomplete decltypes; i.e. it does not support decltype expressions that are incomplete types.
But that's not the issue. The issue is this: template<typename T> struct S {}; template<typename T> S<T> fun(T) {} typedef decltype(fun(0)) Si_t; // HERE Does the third line force the instantiation of S<int>? Decltype works just fine on incomplete types in the simple case, so far as I know: struct S; extern S s; typedef decltype(s) S_t; // OK -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Mar 6, 2012, at 11:59 PM, Eric Niebler wrote:
On 3/6/2012 8:45 PM, Daniel Walker wrote:
On Mar 6, 2012, at 11:09 PM, Eric Niebler wrote:
On 3/6/2012 6:27 PM, Daniel Walker wrote:
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote:
BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE?
Ambiguous. Does that mean that decltype support is incomplete or that decltype doesn't force type-completeness?
BOOST_NO_INCOMPLETE_DECLTYPE means the compiler does not support incomplete decltypes; i.e. it does not support decltype expressions that are incomplete types.
But that's not the issue. The issue is this:
template<typename T> struct S {}; template<typename T> S<T> fun(T) {} typedef decltype(fun(0)) Si_t; // HERE
Does the third line force the instantiation of S<int>?
Decltype works just fine on incomplete types in the simple case, so far as I know:
struct S; extern S s; typedef decltype(s) S_t; // OK
Oh yeah, I forgot this only comes up with call expressions. How about BOOST_NO_INCOMPLETE_DECLTYPE_CALL_EXPRESSIONS? The macro means the compiler does not support incomplete decltypes of call expressions. - Daniel
On 3/6/2012 9:28 PM, Daniel Walker wrote:
On Mar 6, 2012, at 11:59 PM, Eric Niebler wrote:
On 3/6/2012 8:45 PM, Daniel Walker wrote:
On Mar 6, 2012, at 11:09 PM, Eric Niebler wrote:
On 3/6/2012 6:27 PM, Daniel Walker wrote:
On Mar 6, 2012, at 9:04 PM, Eric Niebler wrote:
On 3/6/2012 5:10 PM, Michel Morin wrote: > BTW, BOOST_NO_DECLTYPE_N3276 needs to be a more descriptive name?
I couldn't think of a better name, and BOOST_NO_DECLTYPE_ON_FUNCTION_CALL_EXPRESSION_FORCES_TYPE_COMPLETENESS is too long.
:-P
How about BOOST_NO_INCOMPLETE_DECLTYPE?
Ambiguous. Does that mean that decltype support is incomplete or that decltype doesn't force type-completeness?
BOOST_NO_INCOMPLETE_DECLTYPE means the compiler does not support incomplete decltypes; i.e. it does not support decltype expressions that are incomplete types.
But that's not the issue. The issue is this:
template<typename T> struct S {}; template<typename T> S<T> fun(T) {} typedef decltype(fun(0)) Si_t; // HERE
Does the third line force the instantiation of S<int>?
Decltype works just fine on incomplete types in the simple case, so far as I know:
struct S; extern S s; typedef decltype(s) S_t; // OK
Oh yeah, I forgot this only comes up with call expressions. How about BOOST_NO_INCOMPLETE_DECLTYPE_CALL_EXPRESSIONS? The macro means the compiler does not support incomplete decltypes of call expressions.
That's better, I suppose. It's not 100% accurate to say that the compiler doesn't support incomplete call expressions, though. If a compiler doesn't implement N3276, it still supports incomplete call expressions and usually gets the right answer, but it could potentially instantiate a template unnecessarily in the process. (And this could set off an infinite cascade of such template instantiations, which causes your computer to catch fire and burn off your eyebrows.) So I dunno. I still lean toward BOOST_NO_DECLTYPE_N3276 because nothing pithy seems to really get at the gist of it. And I don't expect this macro to be used outside of Boost itself. But I don't have a strong feeling about it. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Mar 06, 2012 at 09:38:45PM -0800, Eric Niebler wrote:
On 3/6/2012 9:28 PM, Daniel Walker wrote:
Oh yeah, I forgot this only comes up with call expressions. How about BOOST_NO_INCOMPLETE_DECLTYPE_CALL_EXPRESSIONS? The macro means the compiler does not support incomplete decltypes of call expressions.
That's better, I suppose. It's not 100% accurate to say that the compiler doesn't support incomplete call expressions, though. If a compiler doesn't implement N3276, it still supports incomplete call expressions and usually gets the right answer, but it could potentially instantiate a template unnecessarily in the process. (And this could set off an infinite cascade of such template instantiations, which causes your computer to catch fire and burn off your eyebrows.)
So I dunno. I still lean toward BOOST_NO_DECLTYPE_N3276 because nothing pithy seems to really get at the gist of it. And I don't expect this macro to be used outside of Boost itself. But I don't have a strong feeling about it.
How about some documentation or at least a comment somewhere in Boost.Config about what it implies, even if it's just a link to the paper? I'd reckon that anyone that encounters it in source will want to try to find out what it means, in some indirect way. There's nothing worse than when good information only exists deep in some thread on a mailing list. -- Lars Viklund | zao@acc.umu.se
So I dunno. I still lean toward BOOST_NO_DECLTYPE_N3276 because nothing pithy seems to really get at the gist of it. And I don't expect this macro to be used outside of Boost itself. But I don't have a strong feeling about it.
How about some documentation or at least a comment somewhere in Boost.Config about what it implies, even if it's just a link to the paper?
I'd reckon that anyone that encounters it in source will want to try to find out what it means, in some indirect way.
That's what we do, the docs for that macro just say: The compiler does not support the extension to `decltype` described in [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3276.pdf N3276], accepted in Madrid, March 2011. Which is pretty short granted, but at a link to the paper is there. HTH, John.
John Maddock wrote:
PS should we just give you write access for these patches?
If it is convenient for you and no one objects, then it would be great for me to have a write access to the clang compiler config. It would be also great, if possible, to have a write access to Boost.Config for fixing super-minor bugs (like typos). Regards, Michel
John Maddock wrote:
PS should we just give you write access for these patches?
If it is convenient for you and no one objects, then it would be great for me to have a write access to the clang compiler config.
It would be also great, if possible, to have a write access to Boost.Config for fixing super-minor bugs (like typos).
There's an invitation on it's way, John.
participants (5)
-
Daniel Walker -
Eric Niebler -
John Maddock -
Lars Viklund -
Michel Morin