if-constexpr short circuiting ambiguity?

[left...@gmail.com]

Forgive me if this has already been answered or I'm posting to the wrong forum.

I was just reading the if-constexpr proposal that was accepted in Oulu (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0292r1.html, I believe) and trying out the implementation that's currently on clang's trunk. I believe there is an unresolved question about short circuiting.

Example:

#include <iostream>

#include <type_traits>

struct MyType

{

  static const int i = 5;

};

template<typename T>

void do_thing(const T &t)

{

  if constexpr (std::is_same_v<MyType, T> && T::i == 5) {

    std::cout << "MyType::i == 5\n";

  } else {

    std::cout << "don't know...\n";

  }

}

int main()

{

  do_thing(MyType());

  do_thing(3); // fails to compile because of the T::i expression in the if-constexpr above

}

This code fails to compile in the current implementation of if-constexpr in clang.

However, the equivalent code:

#include <type_traits>


struct MyType
{
  static const int i = 5;
};

template<typename T>
  auto do_thing(const T &t) -> std::enable_if_t<std::is_same<MyType, T>::value && T::i == 5>
{
}

template<typename T>
  auto do_thing(const T &t) -> std::enable_if_t<!std::is_same<MyType, T>::value>
{
}

int main()
{
  do_thing(MyType());
  do_thing(3);
}

Succeeds to compile.

It would be my opinion that the if-constexpr conditional *should* short-circuit at compile time, but I don't see if the accepted proposal specifies one way or the other.

Thank you,

Jason

[Jens Maurer]

The condition for the if-constexpr is instantiated as a whole,
and needs to be valid. You can nest the if-constexpr, though:

if constexpr (std::is_same_v<MyType, T>)
if constexpr (T::i == 5) // not instantiated if outer condition is false
...

Jens

> --
> 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 <mailto:std-proposal...@isocpp.org>.
> To post to this group, send email to std-pr...@isocpp.org <mailto:std-pr...@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d2934cdf-6a6e-47c7-aa04-660847a8167b%40isocpp.org <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d2934cdf-6a6e-47c7-aa04-660847a8167b%40isocpp.org?utm_medium=email&utm_source=footer>.

[Zhihao Yuan]

On Tue, Jun 28, 2016 at 11:33 PM, <left...@gmail.com> wrote:
>
>
> Succeeds to compile.
>
> It would be my opinion that the if-constexpr conditional *should*
> short-circuit at compile time, but I don't see if the accepted proposal
> specifies one way or the other.

It compiles not because of short-circuit but sfinae in
general; it still works if you swap the sub-expressions
around &&. If that is the behavior you expect we
need to say that substitution failures give false values.
However, I'm skeptical about its generality.

The constexpr if example you gave is truly equiv to
the following:

#include <type_traits>

struct MyType
{
static const int i = 5;
};

template<typename T>

auto do_thing(const T &t, std::true_type)
{
}

template<typename T>
auto do_thing(const T &t, std::false_type)
{

}

template<typename T>
auto do_thing(const T &t)

{
return do_thing(t, std::bool_constant<std::is_same_v<MyType, T> &&
T::i == 5>());
}

int main()
{
do_thing(MyType());
do_thing(3);
}

, which doesn't work in the same way.

OK, Jens answered it... And it's way better than
what I'm going to suggest, which is based on
constexpr lambda expression sfinae...

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

[left...@gmail.com]

These are the replies I expected to see. 

Should the language of the constexpr-if documentation needs to be updated to say that the entire condition must be well-formed / it is compiled as a whole? I did not see that explicitly stated in the proposal.

-Jason

[Patrice Roy]

Hi Jason!

If you think this is the direction it should go. how about a proposal that explores the pros and cons of it? It might be interesting, and it would seem intuitive at first glance, but the devil's in the details so such a proposal would definitely be useful.

Cheers!

--

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/9a3f181e-acd2-4400-8dfa-b692cdf7cfb8%40isocpp.org.

[Richard Smith]

On Wed, Jun 29, 2016 at 5:19 AM, <left...@gmail.com> wrote:

These are the replies I expected to see. 

Should the language of the constexpr-if documentation needs to be updated to say that the entire condition must be well-formed / it is compiled as a whole? I did not see that explicitly stated in the proposal.

What documentation are you referring to?

The standard is a specification, not a tutorial, and it specifies what it needs to in this case. The specified behavior for instantiation of a function template is that the entire function body is instantiated; constexpr if explicitly opts out its unchosen controlled statement from this, but says nothing about its condition, so the normal rules apply there.

It's really up to the paper author to decide what details they cover in their paper, but the primary purpose of those papers is as input to the committee process rather than communication with the rest of the world, and in the committee discussion we did talk about this case.

On the other hand, I would certainly expect this to be something that someone teaching this feature would mention.

--

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.

[left...@gmail.com]

I was referring to the text of the accepted proposal.

The question I've been attempting to ask is: "does the language of the standard need to be clarified?" the answer appears to be "no."

-Jason