An 'if constexpr branch' does not get discarded inside lambda that is inside a template functionC++0x error with constexpr and returning template functionPossible to instantiate templates using a for loop in a C++14 constexpr function?Calling `this` member function from generic lambda - clang vs gccInitializing a static constexpr data member of the base class by using a static constexpr data member of the derived classSFINAE constexpr with std::getStatic templated constexpr nested class memberShould decltype(foo(1)) instantiate the constexpr function template foo?Why can't lambda, when cast to function pointer, be used in constexpr context?False-branch of if constexpr not discarded in templated lambdaNested constexpr-if statement in discarded branch is still evaluated?

If Earth is tilted, why is Polaris always above the same spot?

How can I fairly adjudicate the effects of height differences on ranged attacks?

Visa for volunteering in England

The barbers paradox first order logic formalization

Why do freehub and cassette have only one position that matches?

Selecting a secure PIN for building access

What is the most remote airport from the center of the city it supposedly serves?

Can fracking help reduce CO2?

Conflicting terms and the definition of a «child»

How to implement float hashing with approximate equality

Was Hulk present at this event?

Why do money exchangers give different rates to different bills

Unexpected email from Yorkshire Bank

Was Unix ever a single-user OS?

How could a planet have most of its water in the atmosphere?

Junior developer struggles: how to communicate with management?

How to avoid grep command finding commented out strings in the source file?

How long can a 35mm film be used/stored before it starts to lose its quality after expiry?

Transfer over $10k

What does air vanishing on contact sound like?

Is this homebrew race based on the Draco Volans lizard species balanced?

Applying a function to a nested list

Can I use 1000v rectifier diodes instead of 600v rectifier diodes?

If Melisandre foresaw another character closing blue eyes, why did she follow Stannis?



An 'if constexpr branch' does not get discarded inside lambda that is inside a template function


C++0x error with constexpr and returning template functionPossible to instantiate templates using a for loop in a C++14 constexpr function?Calling `this` member function from generic lambda - clang vs gccInitializing a static constexpr data member of the base class by using a static constexpr data member of the derived classSFINAE constexpr with std::getStatic templated constexpr nested class memberShould decltype(foo(1)) instantiate the constexpr function template foo?Why can't lambda, when cast to function pointer, be used in constexpr context?False-branch of if constexpr not discarded in templated lambdaNested constexpr-if statement in discarded branch is still evaluated?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








18















The following code:



#include <type_traits>

struct X
static constexpr void x()
;

template <class T1, class T2>
constexpr bool makeFalse() return false;

template <class T>
void foo()
T tmp;
auto f = [](auto type)
if constexpr (makeFalse<T, decltype(type)>())
T::x(); // <- clang does not discard
else
// noop

;


int main()
foo<int>();



does not compile with Clang, but compiles with GCC. I can't see anything wrong with this code, but I'm not sure. Is Clang right not compiling it?










share|improve this question
























  • worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

    – bolov
    5 hours ago











  • (somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

    – bolov
    5 hours ago







  • 1





    @bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

    – Amadeus
    5 hours ago

















18















The following code:



#include <type_traits>

struct X
static constexpr void x()
;

template <class T1, class T2>
constexpr bool makeFalse() return false;

template <class T>
void foo()
T tmp;
auto f = [](auto type)
if constexpr (makeFalse<T, decltype(type)>())
T::x(); // <- clang does not discard
else
// noop

;


int main()
foo<int>();



does not compile with Clang, but compiles with GCC. I can't see anything wrong with this code, but I'm not sure. Is Clang right not compiling it?










share|improve this question
























  • worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

    – bolov
    5 hours ago











  • (somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

    – bolov
    5 hours ago







  • 1





    @bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

    – Amadeus
    5 hours ago













18












18








18


5






The following code:



#include <type_traits>

struct X
static constexpr void x()
;

template <class T1, class T2>
constexpr bool makeFalse() return false;

template <class T>
void foo()
T tmp;
auto f = [](auto type)
if constexpr (makeFalse<T, decltype(type)>())
T::x(); // <- clang does not discard
else
// noop

;


int main()
foo<int>();



does not compile with Clang, but compiles with GCC. I can't see anything wrong with this code, but I'm not sure. Is Clang right not compiling it?










share|improve this question
















The following code:



#include <type_traits>

struct X
static constexpr void x()
;

template <class T1, class T2>
constexpr bool makeFalse() return false;

template <class T>
void foo()
T tmp;
auto f = [](auto type)
if constexpr (makeFalse<T, decltype(type)>())
T::x(); // <- clang does not discard
else
// noop

;


int main()
foo<int>();



does not compile with Clang, but compiles with GCC. I can't see anything wrong with this code, but I'm not sure. Is Clang right not compiling it?







c++ c++17 if-constexpr






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 1 hour ago









Peter Mortensen

14k1987114




14k1987114










asked 6 hours ago









nicolainicolai

336211




336211












  • worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

    – bolov
    5 hours ago











  • (somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

    – bolov
    5 hours ago







  • 1





    @bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

    – Amadeus
    5 hours ago

















  • worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

    – bolov
    5 hours ago











  • (somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

    – bolov
    5 hours ago







  • 1





    @bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

    – Amadeus
    5 hours ago
















worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

– bolov
5 hours ago





worth mentioning that T is not dependant on the lambda template parameter. Don't know however how if constexpr should handle that.

– bolov
5 hours ago













(somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

– bolov
5 hours ago






(somewhat) equivalent example without lambda compiles fine , so I suspect it's a clang bug godbolt.org/z/Xok1wC

– bolov
5 hours ago





1




1





@bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

– Amadeus
5 hours ago





@bolov if you remove the generic lambda, it compiles too: godbolt.org/z/xoTBT6

– Amadeus
5 hours ago












1 Answer
1






active

oldest

votes


















11














[stmt.if]/2:




During the instantiation of an enclosing templated entity, if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.




Since makeFalse<T, decltype(type)>() is value-dependent after the instantiation of foo<int>, it appears that T::x() should be instantiated per the standard, and since T::x is ill-formed when T is int, Clang is right not compiling it.






share|improve this answer























  • Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

    – Barry
    3 hours ago











  • @Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

    – cpplearner
    3 hours ago












  • I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

    – Barry
    3 hours ago











  • I am not convinced. Why then are my example and Amadeus compiling?

    – bolov
    3 hours ago







  • 3





    @Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

    – cpplearner
    3 hours ago











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55909018%2fan-if-constexpr-branch-does-not-get-discarded-inside-lambda-that-is-inside-a-t%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









11














[stmt.if]/2:




During the instantiation of an enclosing templated entity, if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.




Since makeFalse<T, decltype(type)>() is value-dependent after the instantiation of foo<int>, it appears that T::x() should be instantiated per the standard, and since T::x is ill-formed when T is int, Clang is right not compiling it.






share|improve this answer























  • Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

    – Barry
    3 hours ago











  • @Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

    – cpplearner
    3 hours ago












  • I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

    – Barry
    3 hours ago











  • I am not convinced. Why then are my example and Amadeus compiling?

    – bolov
    3 hours ago







  • 3





    @Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

    – cpplearner
    3 hours ago















11














[stmt.if]/2:




During the instantiation of an enclosing templated entity, if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.




Since makeFalse<T, decltype(type)>() is value-dependent after the instantiation of foo<int>, it appears that T::x() should be instantiated per the standard, and since T::x is ill-formed when T is int, Clang is right not compiling it.






share|improve this answer























  • Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

    – Barry
    3 hours ago











  • @Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

    – cpplearner
    3 hours ago












  • I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

    – Barry
    3 hours ago











  • I am not convinced. Why then are my example and Amadeus compiling?

    – bolov
    3 hours ago







  • 3





    @Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

    – cpplearner
    3 hours ago













11












11








11







[stmt.if]/2:




During the instantiation of an enclosing templated entity, if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.




Since makeFalse<T, decltype(type)>() is value-dependent after the instantiation of foo<int>, it appears that T::x() should be instantiated per the standard, and since T::x is ill-formed when T is int, Clang is right not compiling it.






share|improve this answer













[stmt.if]/2:




During the instantiation of an enclosing templated entity, if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.




Since makeFalse<T, decltype(type)>() is value-dependent after the instantiation of foo<int>, it appears that T::x() should be instantiated per the standard, and since T::x is ill-formed when T is int, Clang is right not compiling it.







share|improve this answer












share|improve this answer



share|improve this answer










answered 5 hours ago









cpplearnercpplearner

6,24122644




6,24122644












  • Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

    – Barry
    3 hours ago











  • @Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

    – cpplearner
    3 hours ago












  • I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

    – Barry
    3 hours ago











  • I am not convinced. Why then are my example and Amadeus compiling?

    – bolov
    3 hours ago







  • 3





    @Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

    – cpplearner
    3 hours ago

















  • Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

    – Barry
    3 hours ago











  • @Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

    – cpplearner
    3 hours ago












  • I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

    – Barry
    3 hours ago











  • I am not convinced. Why then are my example and Amadeus compiling?

    – bolov
    3 hours ago







  • 3





    @Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

    – cpplearner
    3 hours ago
















Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

– Barry
3 hours ago





Wouldn't this reasoning imply that a hypothetical if constexpr (makeFalse<decltype(type)>) type.x(); would not be discarded either?

– Barry
3 hours ago













@Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

– cpplearner
3 hours ago






@Barry Yes. But type.x() is a dependent and possibly valid expression after the instantiation.

– cpplearner
3 hours ago














I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

– Barry
3 hours ago





I think "possibly valid" is muddling things, I don't think that's relevant necessarily. Are you saying it won't be discarded even if makeFalse<decltype(type)> is false? Assume it's actually an interesting check... more like if constexpr (can_x<decltype(type)>) type.x();

– Barry
3 hours ago













I am not convinced. Why then are my example and Amadeus compiling?

– bolov
3 hours ago






I am not convinced. Why then are my example and Amadeus compiling?

– bolov
3 hours ago





3




3





@Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

– cpplearner
3 hours ago





@Barry Let me try to clarify. There are two instantiations that can be involved: (1) the instantiation of foo (2) the instantiation of f's function call operator template (which does not happen in OP's example). (1) does not discard either branch, because the condition is still value-dependent after it. If either branch is ill-formed after (1), an error will occur (but [temp.res]/8 may kick in when an expression in a branch is dependent). (2) does discard one branch because the condition is no longer dependent.

– cpplearner
3 hours ago



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55909018%2fan-if-constexpr-branch-does-not-get-discarded-inside-lambda-that-is-inside-a-t%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

Ласкавець круглолистий Зміст Опис | Поширення | Галерея | Примітки | Посилання | Навігаційне меню58171138361-22960890446Bupleurum rotundifoliumEuro+Med PlantbasePlants of the World Online — Kew ScienceGermplasm Resources Information Network (GRIN)Ласкавецькн. VI : Літери Ком — Левиправивши або дописавши її