Visual studio with c++17 build failed

[BartolomeyKant]

The minimum example to reproduce:

#include <iostream>

#include <unifex/just.hpp>
#include <unifex/let_value.hpp>

using namespace unifex;

struct MainRecv {
	template<typename V>
	void set_value(V&& v) noexcept { std::cout << " v=" << v;  }
	template<typename E>
	void set_error(E&&) noexcept { std::cerr << " error="; }
	void set_done() noexcept { std::cout << "DONE"; }
};

int main() {
        // failed with `let_value` and `let_error`. `then` works fine.
        // maybe other senders returning senders also affected. 
	auto sender = just(12) | let_value([](int i) { return just(1); });
	auto op = connect(std::move(sender), MainRecv{});  // error generated while connect
	start(op);
}

The error log I get on my machine:
msvc_build_failed.log

cl /std:c++20 works just fine. The problem only with cl /std:c++17.

cl version on my machine is:

Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35217 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

[BartolomeyKant]

I manged somehow to make more simple example, and it mostly not related to any sender type.

#include <iostream>

#include <unifex/just.hpp>
#include <unifex/receiver_concepts.hpp>
#include <unifex/sender_concepts.hpp>

using namespace unifex;

// define to 1 to get error
#define FOO 1

struct MainRecv {
	template<typename V>
	void set_value(V&& v) && noexcept { std::cout << " v=" << v;  }
	template<typename E>
	void set_error(E&&) && noexcept { std::cerr << " error="; }
	void set_done() && noexcept { std::cout << "DONE"; }
};

#if FOO
template<typename Operation>
struct NR
{ struct type; };
#else
template<typename Operation>
struct NR;
#endif

#if FOO
template<typename Operation>
using NestedRecv = typename NR<Operation>::type;
#else
template<typename Operation>
using NestedRecv = NR<Operation>;
#endif

template<typename Operation>
struct NR
#if FOO
	<Operation>::type
#endif
{
	// this is a crucial part
	using receiver_type = typename Operation::receiver_type;
	
	Operation& op;

	template<typename V>
	void set_value(V&& v) && noexcept { std::move(op.r_).set_value(std::forward<V>(v)); }
	template<typename E>
	void set_error(E&& e) && noexcept { std::move(op.r_).set_error(std::forward<E>(e)); }
	void set_done() && noexcept { std::move(op.r_).set_done(); }
};

template<typename Sender, typename Receiver>
struct Op {
	struct type;
};

template<typename Sender, typename Receiver>
using Operation = typename Op<Sender, Receiver>::type;

template<typename Sender, typename Receiver>
struct Op<Sender, Receiver>::type {
	using receiver_type = Receiver;
	using n_recv = NestedRecv<type>;
	using NestedOp = connect_result_t<Sender, n_recv >;
    
	type(Sender&& s, Receiver&& r) : r_{ std::move(r) },
		n_op_{ connect(std::move(s), n_recv {*this}) } {
	}

	void start() noexcept {
		unifex::start(n_op_);
	}

	Receiver r_;
	NestedOp n_op_;
};

int main() {
	auto op = Operation<decltype(just(12)), MainRecv>{ just(12), MainRecv{} };
	start(op);
}

If you #define FOO 0 at the beginning of listing all compiles fine. But if you #define FOO 1 it fails.

It fails on creating alias to receiver_type.

I'm not sure about the reason but I think it somehow related to cycle dependency between Op<Sender, Receiver>::type and NR<Operation>::type.

BTW, Why does unifex always using those struct op_ { struct type; } instead of just struct op_; ?

[BartolomeyKant]

Even simpler example without unifex https://godbolt.org/z/Gjej6vj6o

[MaxMotovilov]

Your last example is great - truly feels to be a compiler bug :-(

[MaxMotovilov]

BTW, Why does unifex always using those struct op_ { struct type; } instead of just struct op_; ?

I think I've seen places where it actually serves a cause (complex dependencies between templates) but in most cases it surely feels like following an established pattern. Admittedly I stopped doing it myself in new components when it doesn't seem to be helpful.

[MaxMotovilov]

Hmm - lookitthat... https://godbolt.org/z/WMhxTzhsT

Some magic handwaving does away with the issue. Wonder if this is applicable to unifex codebase... maybe you'll try and see how bad it proves to look?

[BartolomeyKant]

Some magic handwaving does away with the issue. Wonder if this is applicable to unifex codebase... maybe you'll try and see how bad it proves to look?

I've asked DeepSeek about this bug and it suggested similar workaround.

Also It explains the problem related to buggy or incomplete implementation of two-phase lookup in msvc, and it was fixed in c++20 by the standard itself.

Also one of the solution might be to use trait class like:

template<typename Operation>
struct OpTrait {
  using receiver_type = typename Operation::receiver_type;
  template <typename... Values>
  using successor_operation = typename Operation::template successor_operation<Values...>;
  template <typename... Values>
  using successor_type = typename Operation::template successor_type<Values...>;
};

Or defer resolving dependencies. Remove using receiver_type = typename Operation::receiver_type from struct _predecessor_receiver<Operation>::type and add it directly inside the functions there it used.

Or just remove that nested struct type.

I don't like the last because it breaks an established pattern. And the others looks like a clunky workaround.

But as you've mentioned you already breaking the pattern in new components. What solution would fit best here?

[BartolomeyKant]

Or just remove that nested struct type.

I changed my mind. It works, and it only requires remove lines of code, not add new. "Less code less bugs" - works as usual.

[MaxMotovilov]

IMO the one that changes the least amount of code. In all honesty, supporting MSVC in C++17 mode is not a high priority for the users I am aware of (which means primarily Meta). I am curious why do you need it when C++20 is available?

[BartolomeyKant]

I am curious why do you need it when C++20 is available

We are building the client library. https://github.com/aethernetio/aether-client-cpp
And we want it to be available for the wider range of developers as possible. And since there are still a lot of companies using c++17 based toolchains including embeded vendor-specific.

I'm not an expert on all of this and didn't make the analysis by myself. For me it's just a strategy chosen by the company owner.

We already has an inhouse solution for asynchronous operations but it's heavy by design. So I want to use it only for specific operations and replace the most with executors. I've explored some JS-like future/promise implementations but they are using type erasure with heap allocation on each .then step. I like what executors make a big templated object first and then I could wrap it into any_sender_of with one heap allocation or place directly on stack.

Support for c++17 stated in unifex's readme and I don't see any actual technical limitations to break that statement.

[BartolomeyKant]

After a few tries to fix it and some investigation I decided to give up.
Setting /permissive- fixes all the errors.

And I give up not because finding fix for every error is difficult but because I found non permissive mode also has problems with tag_invoke approach. Read about hidden friends.

I think it would be a good idea to just add note into readme about /permissive- flag. And because this flag exists since Visual Studio 2017 we still can say - unifex supports c++17.